4 ms·

Ok, wait. Time out. What whould be the difference between: try{ some ifs ... return x ... more ifs ... throw ... return y }catch{

Ok, wait. Time out. What whould be the difference between: try{ some ifs ... return x ... more ifs ... throw ... return y }catch{ handle exceptions }finally{ do_something_finally() } and try{ some ifs ... return x ... more ifs ... throw ... return y }catch{ handle exceptions } do_something_finally() I'm missing something, I'm not?

gfodor 16y ago
No, you're right. The code in the above example behaves differently than the finally version in the case where UNLOCK TABLE throws something. This seems to be an example where the hack is preferred over the correct solution. The hack in this case is going to work almost all of the time. I fail to see how throwing up an example of a hack is a good way to argue for or against a language feature. Generally speaking if the language is decent enough there is always a way to hack in some new semantics yourself (I'm looking at you, anonymous inner Java classes for closures), but language features allow you to compose and represent those semantics more elegantly. So, the argument shouldn't be "can we do this already with a hack" it should be "is this hack common enough that we should fix it." The point the author is making is almost self-evidentally against his own conclusion: here's a common pattern that is broken, so we should not include this as a language feature???
bnoordhuis 16y ago
Without the finally block, do_something_finally() will not be called if: 1. the try block returns 2. the catch block doesn't handle /all/ types of exceptions The point of finally is that it's always, always, always executed.
- BrandonM 16y ago
  > The point of finally is that it's always, always, always executed. Except when it's not. If you design a large system with the assumption that finally blocks always execute, you could end up with some data integrity issues when you get a power outage, an exception in your finally clause, a hung machine, or any other number of errors that a finally clause does nothing to address. The finally clause is very useful, but to say that it will always (x3!) execute is somewhat perilous.
MindTwister 16y ago
According to the linked article, the second one will not run do_something_finall() since it is after the return statement. The second one however will... Note, this does seem to be the case for javascript: With finally http://jsfiddle.net/J5Cjt/ http://jsfiddle.net/J5Cjt/ Without finally http://jsfiddle.net/C2vg7/ http://jsfiddle.net/C2vg7/
trezor 16y ago
Your first example will do_something_finally() before returning y and exiting the try-scope and method (unless an error has occurred). Your second example will return y without invoking do_something finally() (unless an error has occurred). If an error occurs before "return y", both will behave equally. Basically the finally-clause is guaranteed to be run always. This means that you can put your resource-cleanup logic there and know it will be invoked if errors occur or not, without the need to duplicate that logic within the catch-block. Especially when the catch-block is set to rethrow (or just outright omitted) this saves the programmer a lot of time, code-duplication and makes the code more readable. The reasons given for omitting it by the PHP team is factually incorrect and shows that they clearly don't understand how the feature is supposed to work. With that hindsight, it would be interesting to see how it would have been implemented if they had gone forward adding it instead of saying "no". It could have become a highly fascinating monster.
yummyfajitas 16y ago
In this case, do_something_finally() will never be called. try { throw new IOException("bad"); } catch ( NotAnIOException e) { System.out.println("This is something I expected to happen."); } do_something_finally(); With a finally block, it would be, and the IOException would then be bubbled up to the caller. Without finally, you need to do this: try { throw new IOException("bad"); } catch ( NotAnIOException e) { System.out.println("This is something I expected to happen."); } catch (Exception e) { do_something_finally(); throw e; } do_something_finally();
- dan_netwalker 16y ago
  Thanks, now that has a lot more sense

gfodor 16y ago

No, you're right. The code in the above example behaves differently than the finally version in the case where UNLOCK TABLE throws something. This seems to be an example where the hack is preferred over the correct solution. The hack in this case is going to work almost all of the time. I fail to see how throwing up an example of a hack is a good way to argue for or against a language feature. Generally speaking if the language is decent enough there is always a way to hack in some new semantics yourself (I'm looking at you, anonymous inner Java classes for closures), but language features allow you to compose and represent those semantics more elegantly. So, the argument shouldn't be "can we do this already with a hack" it should be "is this hack common enough that we should fix it." The point the author is making is almost self-evidentally against his own conclusion: here's a common pattern that is broken, so we should not include this as a language feature???

bnoordhuis 16y ago

Without the finally block, do_something_finally() will not be called if: 1. the try block returns 2. the catch block doesn't handle /all/ types of exceptions The point of finally is that it's always, always, always executed.

BrandonM 16y ago
> The point of finally is that it's always, always, always executed. Except when it's not. If you design a large system with the assumption that finally blocks always execute, you could end up with some data integrity issues when you get a power outage, an exception in your finally clause, a hung machine, or any other number of errors that a finally clause does nothing to address. The finally clause is very useful, but to say that it will always (x3!) execute is somewhat perilous.

MindTwister 16y ago

According to the linked article, the second one will not run do_something_finall() since it is after the return statement. The second one however will... Note, this does seem to be the case for javascript: With finally http://jsfiddle.net/J5Cjt/ http://jsfiddle.net/J5Cjt/ Without finally http://jsfiddle.net/C2vg7/ http://jsfiddle.net/C2vg7/

trezor 16y ago

Your first example will do_something_finally() before returning y and exiting the try-scope and method (unless an error has occurred). Your second example will return y without invoking do_something finally() (unless an error has occurred). If an error occurs before "return y", both will behave equally. Basically the finally-clause is guaranteed to be run always. This means that you can put your resource-cleanup logic there and know it will be invoked if errors occur or not, without the need to duplicate that logic within the catch-block. Especially when the catch-block is set to rethrow (or just outright omitted) this saves the programmer a lot of time, code-duplication and makes the code more readable. The reasons given for omitting it by the PHP team is factually incorrect and shows that they clearly don't understand how the feature is supposed to work. With that hindsight, it would be interesting to see how it would have been implemented if they had gone forward adding it instead of saying "no". It could have become a highly fascinating monster.

yummyfajitas 16y ago

In this case, do_something_finally() will never be called. try { throw new IOException("bad"); } catch ( NotAnIOException e) { System.out.println("This is something I expected to happen."); } do_something_finally(); With a finally block, it would be, and the IOException would then be bubbled up to the caller. Without finally, you need to do this: try { throw new IOException("bad"); } catch ( NotAnIOException e) { System.out.println("This is something I expected to happen."); } catch (Exception e) { do_something_finally(); throw e; } do_something_finally();

dan_netwalker 16y ago
Thanks, now that has a lot more sense