Sorry for the garbled post, this should hopefully be plain text:
On Thu, 2009-10-01 at 03:29 +0000, Brian Bloniarz wrote:
I.e. why does an exception raised during exception handling get propagated past the exception that triggered the handler?
Because it's the obvious and sensible thing to do and it what every other mainstream language with exceptions does. The behaviour you want, to automatically discard any exceptions raised in the handler and to always re-raise the original exception can be implemented using the current semantics, but the reverse is not true.
Good to know ... C++ (the mainstream language I'm most familiar with) treats throwing from a destructor during unwinding as a fatal error. I was suggesting having bracket ignore exceptions from closeSomeHandle when doAction threw, not that it'd ignore any exceptions from closeSomeHandle. It's only the case where bracket has 2 exceptions to choose from that's ambiguous, and I'm saying that there's a fair amount of code out there that'd prefer to see the first one. Your point about ^C gets us into an even grayer area -- maybe code would prefer to propagate whichever of the 2 exceptions is asynchronous, or define a criterion to choose which exception is more serious, who knows. All these behaviors are easy to implement using the building blocks that Control.Exception exports right now, you're right. So I'm free to build my own bracket variants with different behavior and that's what I'll do. I was just wondering if the default behavior that bracket/onException provide (which are themselves built from catch/block/unblock) is the one that most people want. Thanks, -Brian _________________________________________________________________ Microsoft brings you a new way to search the web. Try Bing™ now http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try bing_1x1