[Haskell-cafe] Exceptions during exception unwinding

[Lyndon Maydwell]

Exception handling code should generally be assumed to work, so if
something goes wrong there you would normally like to know about it.
Also, there is nothing preventing you from wrapping the rescue code in
further exception handling, however, if the initial error were raised
upon encountering a second error, you would not be able to choose to
handle the second error.

This is how I see it anyway.

On Thu, Oct 1, 2009 at 11:29 AM, Brian Bloniarz <phunge0 at hotmail.com> wrote:
>
> I had a question about onException & friends: what's the rationale
> for having:
> (error "foo") `onException` (error "bar")
>
> give bar and not foo? I.e. why does an exception raised during
> exception handling get propagated past the exception that triggered
> the handler?
>
> Most examples I can think for exception unwinding code would prefer the
> original exception be propagated -- for example, HDBC has a function which
> rolls back a DB transaction on exception; it implements it like so:
>> withTransaction conn func =
>>   do r <- onException (func conn) doRollback
>>      commit conn
>>      return r
>>   where doRollback =
>>             -- Discard any exception from (rollback conn) so original
>>             -- exception can be re-raised
>>             Control.Exception.catch (rollback conn) doRollbackHandler
>>         doRollbackHandler :: SomeException -> IO ()
>>         doRollbackHandler _ = return ()
> IMHO, it'd be easier to just write:
>> withTransaction conn func =
>>   do r <- onException (func conn) (rollback conn)
>>      commit conn
>>      return r
>
> This same argument applies to bracket, bracket_, bracketOnError & finally;
> even the common:
>> bracket openSomeHandle closeSomeHandle doAction
> If some error arises during doAction, there's a chance closeSomeHandle might fail
> (even a good chance, given that exception unwinding paths are usually poorly
> tested), and probably doAction has more accurate information about what went
> wrong than closeSomeHandle.
>
> This is just a thought; I hadn't seen this discussed somewhere. I know for
> example that Java has the same approach as the current Control.Exception, so
> there must be good arguments for that too. One that I can think of: using
> onException to rethrow an exception as a different type, though that's what
> mapException is for, correct?
>
> 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_______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>