As part of writing an Iterator, I found myself writing the following piece of code (stripping error handling)public T next() {  try {    return next;  } finally {    next = fetcher.fetchNext(next);  }}finding it slightly easier to read thanpublic T next() {  T tmp = next;  next = fetcher.fetchNext(next);  return tmp;}I know it's a simple example, where the difference in readability may not be that overwhelming, but I'm interested in the general opinion as to whether it is bad to use try-finally in cases like this where there are no exceptions involved, or if it is actually preferred when it simplifies the code.If it's bad: why? Style, performance, pitfalls, ...?ConclusionThanks you all your answers! I guess the conclusion (at least for me) is that the first example might have been more readable if it was a common pattern, but that it isn't. Therefore the confusion introduced by using a construct outside of it's purpose, along with possibly obfuscated exception flow, will outweigh any simplifications.
Is use of finally clause for doing work after return bad style/dangerous?
java;code quality;exceptions;readability
Personally, I'd give a thought to the idea of command query separation.  When you get right down to it, next() has two purposes: the advertised purpose of retrieving the element next, and the hidden side effect of mutating the internal state of next.  So, what you're doing is performing the advertised purpose in the body of the method and then tacking on a hidden side effect in a finally clause, which seems... awkward, though not 'wrong', exactly.  What it really boils down to is how understandable the code is, I'd say, and in this case the answer is meh.  You're trying a simple return statement and then executing a hidden side effect in a code block that's supposed to be for fail-safe error recovery.  What you're doing is 'clever', and 'clever' code often induces maintainers to mumble, what the... oh, I think I get it.  Better for people reading your code to mumble yep, uh-huh, makes sense, yes...So, what if you separated state mutation from accessor calls?  I'd imagine the readability issue you're concerned with becomes moot, but I don't know how that affects your broader abstraction.  Something to consider, anyway.