Lex, I am fine not having the terse syntax of #1. In fact I am not asking why f2() threw an exception. I was only worried why the syntax of f1() lays a trap for me that I will fall in to later.
In other languages I am familiar with, "finally" is orthogonal to what happens inside catch (or whether it is caught at all). If you follow my example above, both f2() and f1() could have been the same code originally and a seemingly unrelated addition of finally changed the behavior of the rest of the code. In terms of having a syntax for all combinations of outcomes - that wasn't my intent. I understand we couldn't possibly have a syntax for all combinations. For example, there can be exception that occurs in the finally block that masks the original exception. I see the behavior as just 'catch', 'rethrow or ignore', 'finally'. Each of these then take its own path. If we require a 'catch' block for every "try", it would be cleaner. Otherwise I suggest we had a note in the documentation to state the caveats. Particularly for those who come from other background and get too excited about "try end" terse syntax. I would be happy to make some edits in the documentation if you approve. Thanks -- Harry On Tuesday, April 7, 2015 at 10:08:53 PM UTC-7, Toivo Henningsson wrote: > > I think you are right that this is deliberate, but I also think that > making catch and finally orthogonal to each other should trump such case by > case optimizations. It would allow a simpler mental model of the language. > If you want the current behavior of > > try end > > you can use > > try catch end > > and I think there is something to be said for the explicitness that comes > with only catching exceptions when there is a catch keyword involved. > > I don't see how ignore in your list below is different from catching an > exception and ignoring it. If you merge those two, your options reduce down > to four, which map naturally to the four combinations of using our not > using catch and finally respectively. > On Tuesday, April 7, 2015 at 10:08:53 PM UTC-7, Toivo Henningsson wrote: > > I think you are right that this is deliberate, but I also think that > making catch and finally orthogonal to each other should trump such case by > case optimizations. It would allow a simpler mental model of the language. > If you want the current behavior of > > try end > > you can use > > try catch end > > and I think there is something to be said for the explicitness that comes > with only catching exceptions when there is a catch keyword involved. > > I don't see how ignore in your list below is different from catching an > exception and ignoring it. If you merge those two, your options reduce down > to four, which map naturally to the four combinations of using our not > using catch and finally respectively. >
