blackholes and exception handling

Simon Marlow marlowsd at
Mon May 3 02:58:28 EDT 2010

On 02/05/10 12:10, Sebastian Fischer wrote:
>>> Is the above output intended?
>> Yes.
> Interesting.
>> Note that catching all exceptions is rarely the right thing to do. See
>> for more details.
> I should have written
> go_ahead :: NonTermination -> IO ()
> in the first place.
>>> The idea behind black-hole detection is that one bottom is as good as
>>> another [1]. Consequently, exception handling may not distinguish
>>> between non-termination and other errors.
>> Pure code can't distinguish, but exception handling code in IO can.
> What makes me wary is that GHC distinguishes between different kinds of
> non-terminating computations (those it can detect as black holes and
> those it can't). As a consequence, the semantics of my program depends
> on how I define the infinite loop don't_launch_first (the program either
> writes to stdout or doesn't).
> For me, it is interesting to notice (and slightly disturbing) that this
> is intended and that the Control.Exception module defines the
> NonTermination exception to explicitly handle black holes.

The imprecise exceptions paper that you referenced describes exactly 
this issue in some detail - see Section 4.4, the semantics of 
getException (which is a simpler version of catch).  Basically, catch is 
non-deterministic, so when the value is _|_ it can make a 
non-deterministic choice between diverging or catching an exception.


More information about the Glasgow-haskell-users mailing list