<div dir="ltr">Thank you, Peter :-) <div><br></div><div>The exception specification hint is helpful – now I got it :-) Here, the exception specification stuff is useful...</div><div><br></div><div>OK, I can intercept now, but I see the solution isn't as easy as just replacing e.g.</div>
<div><br></div><div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">void myUnexpected () {</div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">
std::cerr << "unexpected called\n";</div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px"> throw 0; </div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">
}</div></div><div><br></div><div>by</div><div><br></div><div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">void myUnexpected () {</div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">
std::cerr << "unexpected called\n";</div><div style="font-family:'courier new',monospace;font-size:10.909090995788574px">}</div></div><div><div><br></div><div>... 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?!?</div>
<div><br></div><div>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(...),</div><div><br></div>
<div><div><font face="courier new, monospace">extern "C" void hsqml_init(</font><span style="font-family:'courier new',monospace">void (*freeFun)(HsFunPtr),</span></div><div><font face="courier new, monospace"> void (*freeStable)(HsStablePtr) </font><span style="font-family:'courier new',monospace">) throw() </span><span style="font-family:'courier new',monospace">{</span></div>
<div><font face="courier new, monospace"> std::set_unexpected (myunexpected);</font></div><div><span style="font-family:'courier new',monospace"> throw runtime_error("OOOPS...");</span></div><div><span style="font-family:'courier new',monospace"> ...</span></div>
<div><span style="font-family:'courier new',monospace">}</span></div></div><div><br></div><div>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):<br>
</div><div><br></div><div><div><font face="courier new, monospace">{#fun unsafe hsqml_init as hsqmlInit_</font></div><div><font face="courier new, monospace"> {id `HsFreeFunPtr',</font></div><div><font face="courier new, monospace"> id `HsFreeStablePtr'} -></font></div>
<div><font face="courier new, monospace"> `()' #}</font></div></div><div><br></div><div>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??</div>
<div><br></div><div>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)<div>
<br></div><div>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?</div><div><br></div><div>
If not, there is no issue to worry about. :-)</div><div><br></div><div>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...</div>
<div><br></div><div>Cheers, Nick</div><div><br><div><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-14 0:38 GMT+01:00 Peter Simons <span dir="ltr"><<a href="mailto:simons@cryp.to" target="_blank">simons@cryp.to</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<br>
please note that the handler set by std::unexpected() fires only if a<br>
function violates its exception specification, i.e. the function<br>
<br>
void foobar() throw() { throw 0; }<br>
<br>
would trigger std::unexpected_handler(), but<br>
<br>
void foobar() { throw 0; }<br>
<br>
does not, because there is no "unexpected" exception. Uncaught exceptions,<br>
on the other hand, trigger the function std::terminate(), which by default<br>
translates to std::abort().<br>
<br>
Brandon Allbery pointed this out before, but it's probably worth<br>
repeating: there is no way to catch (or throw) a C++ exception in Haskell.<br>
The internal details of C++ exception handling are "implementation<br>
defined". There is no standard that defines how to implement exceptions,<br>
which means that you cannot even mix code from different C++ compilers if<br>
you want to handle exceptions. Mixing in Haskell code is probably next to<br>
impossible.<br>
<br>
Take care,<br>
Peter<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>