[Haskell] Better Exception Handling

Benjamin Franksen benjamin.franksen at bessy.de
Wed Nov 24 18:39:29 EST 2004

On Thursday 25 November 2004 00:29, Scott Turner wrote:
> John Goerzen wrote:
> > I note, though, that "making an Either into a Monad" doesn't do
> > anything to deal with asynchronous exceptions.
> [ snip]
> > I was referring to exceptions generated by things such as signals,
> > interrupts, certain network errors, stack problems, etc.
> How would you like asynchronous exceptions to fit in?  Your original
> request mentioned that it was annoying to have to use the IO monad for all
> exceptions, particularly when the exceptions occur in deterministic code.
> But the IO monad is plainly appropriate for asynchronous exceptions.

I think the explanation was a bit misleading. Asynchronous exceptions are 
exceptions that can occur *anywhere*, even in purely functional code and even 
if the code itself is completely free of bottoms. A good example is 'heap 
overflow', i.e. insufficient memory even after the GC was run. Another 
example are interrupts and unix signals: they can occur at any time, 
regardless of what the program is doing. More generally, whenever you can 
send a message to a thread that isn't expecting one. Control.Exception 
defines 'throwTo' that gets a threadId as argument. This causes the target 
thread to be interrupted with an asynchronous exception.

Asynchronous exceptions are a rather recent addition to ghc. How they relates 
to your (very interesting) EitherMonad solution is not completely clear to 
me, either.


More information about the Haskell mailing list