Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr

On 07/12/2010 21:30, Mitar wrote:

Hi!

On Wed, Dec 1, 2010 at 10:50 AM, Simon Marlow 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 thread. Cheers, Simon