<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
I have to admit that reading your messages has left me wondering what exactly<br>
it is that you are trying to do? What exactly is the problem that you are<br>
trying to solve?<br></blockquote><div>You exactly got the point (below) with "Your question is how to integrate C++ code that might throw exceptions into Haskell via FFI, right?".</div><div><br></div><div>The only thing I am worried about is that, due to lacking experience, I might introduce unnecessary runtime overhead, as performance is critical. I don't want to disimprove.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><br>
> I see the solution isn't as easy as just replacing e.g.<br>
><br>
> void myUnexpected () {<br>
> std::cerr << "unexpected called\n";<br>
> throw 0;<br>
> }<br>
><br>
> by<br>
><br>
> void myUnexpected () {<br>
> std::cerr << "unexpected called\n";<br>
> }<br>
<br>
</div>I'm not sure whether the purpose of std::unexpected_handler() has become clear.<br>
That function is not supposed to handle exceptions in the sense that it makes<br>
the exception "go away" so that normal program flow can continue. Its purpose<br>
is to translate an unexpected exception -- which the program cannot handle --<br>
into a different one that the program can handle. Maybe this quote from [1]<br>
clarifies the matter:<br>
<br>
| A user-defined std::unexpected_handler is expected to either terminate the<br>
| program or throw an exception. If it throws an exception, one of the<br>
| following three situations may be encountered:<br>
|<br>
| 1) the exception thrown by std::unexpected_handler satisfies the dynamic<br>
| exception specification that was violated earlier. The new exception is<br>
| allowed to escape the function and stack unwinding continues.<br>
|<br>
| 2) the exception thrown by std::unexpected_handler still violates the<br>
| exception specification:<br>
|<br>
| a) however, the exception specification allows std::bad_exception: the<br>
| thrown exception object is destroyed, and std::bad_exception is<br>
| constructed by the C++ runtime and thrown instead.<br>
|<br>
| b) the exception specification does not allow std::bad_exception:<br>
| std::terminate() is called.<br>
<br>
This means that the second myUnexpected() function from above is actually<br>
illegal in this context, because it neither throws an exception nor does it<br>
terminate the program.</blockquote><div>What a delicate question... :-)) :-)) :-)) Better I choose my words careful... Hmmm... certainly... In my case, it's failed DB queries that may be caused by failed SQL queries in a backend behind the C++ code; and as far as I can judge, everything is already handled neatly with no collateral damage to be feared for – roughly, these C++ exceptions say that the SQL code wasn't executed – in (a possible) interactive mode meaning merely "please repeat that query correctly...".</div>
<div><br></div><div>But currently, this appears somewhat complicated by</div><div>(1) termination of the code</div><div>(2) quite terse messages (i.e., I am interested in better debug capabilities, too)</div><div><br></div>
<div>By reading Alexander's link to <a href="http://www.cplusplus.com/reference/exception/set_unexpected/">http://www.cplusplus.com/reference/exception/set_unexpected/</a>, I got the impression that there is reasonable chance there is a simple mechanism behind set_unexpected(...) allows replacing some default code leading to termination by arbitrary code – very attractive under these circumstances –, and facing the question what's the meaning of 'illegal' was second to this...</div>
<div><br></div><div>Anyway, this round went to Murphy – or at least I do not see a way to get the termination avalanche stopped yet.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<br>
> The test code I have chosen for learning about the problem is hsqml by Robin<br>
> Kay, which I consider to be very well done, usually injecting into<br>
> HsQMLManager.{cpp|h}.hsqml_init(...),<br>
><br>
> extern "C"<br>
> void hsqml_init(void (*freeFun)(HsFunPtr), void (*freeStable)(HsStablePtr) ) throw() {<br>
> std::set_unexpected (myunexpected);<br>
> throw runtime_error("OOOPS...");<br>
> ...<br>
> }<br>
<br>
</div>I am not sure what exactly the intention behind that code snippet is. I've<br>
looked into the hsqml source at [2], and the hsqml_init() function there<br>
doesn't look like that.<br></blockquote><div>Certainly, as lines were injected by me (I guess I mentioned at 1st mail) for learning about the problem – with hsqml being needed as a scaffold for this.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<br>
> What puzzles me currently is that, by the descriptions, I would expect<br>
> that terminate() actually is replaced by std::cerr, so that the<br>
> termination displayed in the result happens afterwards – but where??<br>
<br>
</div>I am not sure what you mean by that statement. std:cerr is an object, so it<br>
cannot replace std::terminate(), which is a function.<br></blockquote><div> Please excuse: s/std:cerr/std:cerr.../</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<br>
> In regard of what's my question, there should be something like a<br>
> common/best practice, shouldn't it?<br>
<br>
</div>Your question is how to integrate C++ code that might throw exceptions into<br>
Haskell via FFI, right? Please correct me if that's not the case.<br></blockquote><div>Definitely, modulo performance/overhead. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There is no one true way to accomplish that. Since you cannot catch or throw<br>
C++ exceptions in Haskell, you'll probably have to pass them from C++ to<br>
Haskell manually as a value. For example, the C++ function<br>
<br>
int do_stuff() { ... }<br>
<br>
would need a wrapper like this one:<br>
<br>
enum exception_type { none = 0, runtime_error, logic_error, unknown };<br>
<br>
struct either_exception_or_int<br>
{<br>
exception_type err;<br>
int val;<br>
};<br>
<br>
void do_stuff_(either_exception_or_int * result) throw()<br>
{<br>
try<br>
{<br>
result->err = none;<br>
result->val = do_stuff();<br>
}<br>
catch(std::runtime_error const &) { result->err = runtime_error; }<br>
catch(std::logic_error const &) { result->err = logic_error; }<br>
catch(...) { result->err = unknown; }<br>
}<br>
<br>
Now, on the Haskell side, you'd import do_stuff_() via FFI, and then write<br>
another wrapper<br>
<br>
do_stuff :: IO Int<br>
do_stuff = alloca $ \result -> do<br>
do_stuff_ result<br>
val <- peek result<br>
either throwCxxError return val<br>
<br>
throwCxxError :: CxxExceptionType -> IO a<br>
throwCxxError Runtime_error = throwIO ...<br>
throwCxxError ...<br>
<br>
to throw an appropriate Haskell exception that corresponds to the C++ exception<br>
type.<br></blockquote><div>You exactly concretized the 'Either' approach sketched in my mail, though I would have tried to</div><div>(1) get a union instead of a struct for `either_exception_or_int'</div><div>
(2) use pointers for err/val.</div><div>What I am worried about is that exactly this might result in inappropriate overhead.</div><div><br></div><div>This directly leads to the other suggestion of my mail; to, instead of a union of 2 pointers, let `either_exception_or_int' be just a pointer – somewhat opaque for the Haskell side, which still might pipeline it very efficiently from here to there, while it would be possible to C++ to resolve the pointer addresses. </div>
<div> </div><div>So with my 'illegal' one, I see 3 approaches yet.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm not sure whether anybody has done something like that before, i.e. I cannot<br>
refer you to a concrete Haskell project that demonstrates this technique with<br>
real-world code.<br></blockquote><div><img src="cid:33A@goomoji.gmail" goomoji="33A" style="margin: 0px 0.2ex; vertical-align: middle;"> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> As Alexander states, there is a pleasing zero runtime approach with C++<br>
> exceptions.<br>
<br>
I thought Alexander said the exact opposite, i.e. that C++ does *not* have zero<br>
overhead exceptions?<br></blockquote><div>I referred to his mail just incoming when I answered to you (2014-2-14 9:11, "One unmentioned fact is that the exception mechanism in C++ is designed to allow for implementations to have zero runtime cost. ...") – what he addresses makes me quite less worried that catching C++ exceptions themselves in the FFI would introduce performance issues, than wrapping/unwrapping with Either & Co.</div>
<div><br></div><div>Cheers, Nick</div></div></div></div>