exporting functions which raise exceptions
Manuel M. T. Chakravarty
chak at cse.unsw.edu.au
Wed Jun 12 23:57:50 EDT 2002
Alastair Reid <reid at cs.utah.edu> wrote,
> > We discussed this before and agreed that any uncaught exception in a
> > call back from C to Haskell land aborts the program. If the
> > exceptions is to be propagated from the call back to the main
> > application, it is the FFI user's responsibility to arrange this.
> > (I believe that this is actually noted somewhere in the current
> > spec, if it isn't it should, though.)
> I couldn't see it in the spec and I'm working on the code that
In the FFI Addendum, RC 4 <http://www.cse.unsw.edu.au/~chak/haskell/ffi/>,
Section 3.4, the last two sentences define the behaviour in
the same way as I outlined above.
> implements it at the moment so I thought I'd check instead of assuming
> or relying on a (probably imperfect) scan of the mail archives.
> Unless responses to my requests for clarification point to particular
> sections in the spec., I intend to amend the spec. to match responses.
> (I decided to hold off on modifications to the spec until I have a
> complete implementation that passes a reasonably large set of tests
> rather than doing it a bit at a time and getting bits wrong because I
> lack a complete enough picture.)
So, you are adding this to GHC? 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. For this reason, we felt that the FFI Addendum
should not require a special treatment of these exceptions
by a Haskell system.
More information about the FFI