[Haskell-cafe] Printing of asynchronous exceptions to stderr
marlowsd at gmail.com
Thu Dec 16 10:30:33 CET 2010
On 07/12/2010 21:30, Mitar wrote:
> 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