blackholes and exception handling

Simon Marlow marlowsd at gmail.com
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
>> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#4
>>
>> 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.

Cheers,
	Simon


More information about the Glasgow-haskell-users mailing list