Thank you, Peter :-)
The exception specification hint is helpful – now I got it :-) Here,
the exception specification stuff is useful...
OK, I can intercept now, but I see the solution isn't as easy as just
replacing e.g.
void myUnexpected () {
std::cerr << "unexpected called\n";
throw 0;
}
by
void myUnexpected () {
std::cerr << "unexpected called\n";
}
... is it here where Brandon comes in, as the message gets out, but the
whole still carries the original Exception thrown with it – like you can
shoot yourself by your own bullet before the adversary's one arrives you?!?
The test code I have chosen for learning about the problem is hsqml by
Robin Kay, which I consider to be very well done, usually injecting into
HsQMLManager.{cpp|h}.hsqml_init(...),
extern "C" void hsqml_init(void (*freeFun)(HsFunPtr),
void (*freeStable)(HsStablePtr)
) throw() {
std::set_unexpected (myunexpected);
throw runtime_error("OOOPS...");
...
}
hsqml_init(...), again, is directly called from
Graphics/QML/Internal/BindCore.chs – solely (grep ascertained there is no
other call from the C/C++ code):
{#fun unsafe hsqml_init as hsqmlInit_
{id `HsFreeFunPtr',
id `HsFreeStablePtr'} ->
`()' #}
What puzzles me currently is that, by the descriptions, I would expect that
terminate() actually is replaced by std::cerr, so that the termination
displayed in the result happens afterwards – but where??
In regard of what's my question, there should be something like a
common/best practice,shouldn't it? As I see, catching inside C++ isn't an
issue at all with coarse-grained interfaces, as the overhead doesn't
matter. But I expect there are also some experiences for the case of lots
of calls to do from Haskell to very small C++ jobs – how then? As Alexander
states (just incoming... ;-) there is a pleasing zero runtime approach with
C++ exceptions – great if it that be done via pointer addresses only (i.e.
'virtual Either', addresses that will either point to a 'Left' or 'Right'
instance, but without tag), so there might be no additional overhead...
(though things would go somewhat opaque for the Haskell side)
But is there a practice to do this? If not, would it not mean a certain
overhead to construct/destruct, e.g. Either, lots of time, together with
doing the appropriate conditionals?
If not, there is no issue to worry about. :-)
So my interest is a very practical one – so insn't there hope even in case
there is no standard covering it, as concrete FFI interfacing goes to a
fixed project, let's say Qt4? So experiences might have gathered...
Cheers, Nick
2014-02-14 0:38 GMT+01:00 Peter Simons
Hi Nick,
please note that the handler set by std::unexpected() fires only if a function violates its exception specification, i.e. the function
void foobar() throw() { throw 0; }
would trigger std::unexpected_handler(), but
void foobar() { throw 0; }
does not, because there is no "unexpected" exception. Uncaught exceptions, on the other hand, trigger the function std::terminate(), which by default translates to std::abort().
Brandon Allbery pointed this out before, but it's probably worth repeating: there is no way to catch (or throw) a C++ exception in Haskell. The internal details of C++ exception handling are "implementation defined". There is no standard that defines how to implement exceptions, which means that you cannot even mix code from different C++ compilers if you want to handle exceptions. Mixing in Haskell code is probably next to impossible.
Take care, Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe