[Haskell-cafe] Printing of asynchronous exceptions to stderr

Simon Marlow marlowsd at gmail.com
Thu Dec 16 10:30:33 CET 2010

On 07/12/2010 21:30, Mitar wrote:
> Hi!
> On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>>> Yes, but semantics are different. I want to tolerate some exception
>>> because they are saying I should do this and this (for example user
>>> interrupt, or timeout) but I do not want others, which somebody else
>>> maybe created and I do not want to care about them.
>> Surely if you don't care about these other exceptions, then the right thing
>> to do is just to propagate them?  Why can't they be dealt with in the same
>> way as user interrupt?
> The problem is that Haskell does not support getting back to
> (continue) normal execution flow as there was no exception.

If you can't tolerate certain kinds of exceptions being thrown to a 
thread, then... don't throw them.  If your intention is that the thread 
will continue after receiving a certain kind of exception, then handle 
the exception in a different thread instead.

You have complete control over which asynchronous exceptions are thrown 
to a thread.  You might argue that StackOverflow/HeapOverflow aren't 
under your control - but in fact StackOverflow will never be raised 
inside mask.  If/when we ever implement HeapOverflow we'll make sure it 
has this property too.

I've thought about whether we could support resumption in the past. 
It's extremely difficult to implement - imagine if the thread was in the 
middle of an I/O operation - should the entire I/O operation be 
restarted from the beginning?  If the thread was blocked on an MVar, 
then it has to re-block on the same MVar - but maybe now the MVar is 
full.  Should it be as if the thread was never unblocked?  The only 
sensible semantics is that the exception behaves like an interrupt - but 
we already have support for that, just run the handler in a different 


More information about the Glasgow-haskell-users mailing list