exporting functions which raise exceptions

[Manuel M. T. Chakravarty]

Alastair Reid <reid at cs.utah.edu> wrote,

> Hmmm, yet another 'undefined behaviour'.
> I think I'd prefer that as 'implementation defined'.

I read 'undefined behaviour' as not defined by the Addendum,
which implies that it is 'implementation defined'.  However,
I am not too much attached to the wording.  If there is a
consensus that writing 'implementation defined' sounds nicer
than 'undefined behaviour', I am happy to change it.

> > So, you are adding this to GHC? 
> 
> Hugs.  I figure if that Hugs is going to use the hierarchial libraries
> it had better support the same ffi as GHC and NHC.

That's excellent news :-)

> > When this issue was discussed earlier, I think, SimonM pointed out
> > that (especially in the context of concurrency) it is hard to define
> > what exactly is supposed to happen with such exceptions. 
> 
> I'm not sure I see the difficulty - but I'll go ahead and make up my
> own solution (which will probably be much like what GreenCard does...)

What does GreenCard do?

"Simon Marlow" <simonmar at microsoft.com> wrote,

> The default
> behaviour of terminating the program (and reporting the exception, of
> course) is the safest thing to do in the absence of any alternative
> handling.

This holds especially for GHC, where all Haskell failures,
such as pattern match failures, are turned into exceptions.
Until recently, GHC just died with an uncaught exception
error instead of actually pretty printing the exception and
that caused confusion with a number of (less experienced)
people who had pattern match failures and the like in Gtk+HS
signal handler and couldn't figure out what happened.

Cheers,
Manuel