[Haskell-cafe] C++ exception (from *.so) catchable by Haskell??

[Nick Rudnick]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140214/511409b9/attachment.html>