exporting functions which raise exceptions
Suppose I foreign export (or wrap) a Haskell function and that function raises an exception, calls exit or raises an error. How should this be reflected on the C side? In a batch-mode system (ghc, runhugs, nhc), we need to call a no_return function like exit but should it always be exit or should there be a way for an application to register an alternative function? (e.g., If my Basic interpreter makes a foreign function call into Haskell, I'd like an error in Haskell to bring me back to the Basic REPL not to quit my program). In an interactive system (ghci, Hugs), the right thing to do seems to be to return to the interpreters REPL. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Alastair Reid <reid@cs.utah.edu> wrote,
Suppose I foreign export (or wrap) a Haskell function and that function raises an exception, calls exit or raises an error.
How should this be reflected on the C side?
In a batch-mode system (ghc, runhugs, nhc), we need to call a no_return function like exit but should it always be exit or should there be a way for an application to register an alternative function? (e.g., If my Basic interpreter makes a foreign function call into Haskell, I'd like an error in Haskell to bring me back to the Basic REPL not to quit my program).
In an interactive system (ghci, Hugs), the right thing to do seems to be to return to the interpreters REPL.
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.) Cheers, Manuel
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 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.) -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Alastair Reid <reid@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. Cheers, Manuel
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,
Ah, thank you. Hmmm, yet another 'undefined behaviour'. I think I'd prefer that as 'implementation defined'.
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.
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...) -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Alastair Reid <reid@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@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
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?
It does its best to return to the read eval print loop. If that fails (hmmm, not sure I understand what would cause that failure), it calls exit. A bit more error reporting seems to be called for here... -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
participants (2)
-
Alastair Reid -
Manuel M. T. Chakravarty