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 <simons@cryp.to>:
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