Replace exception handler?
Remo
remo4d at gmail.com
Thu Feb 27 14:56:48 PST 2014
On Thursday, 27 February 2014 at 22:24:23 UTC, Ali Çehreli wrote:
> On 02/27/2014 05:24 AM, Remo wrote:
>
> > Unfortunately I can not find a way to replace exception
> handler in D2.
> > Is there a way to do this?
>
> I think you mean the unhandled exception handler. Otherwise,
> try+catch is the way to provide a handler. ;) I think that
> would not be the solution as it would kick in when the
> application (druntime?) was going down; hence it would be too
> late anyway.
>
> > The problem is that I load a Dll coded in D from Application
> coded in C++.
> > If this Dll throw and exception then there is no way to
> handle it from
> > the Application.
>
> One way is to wrap every API function in a try+catch block on
> the dll side and return an error code and message. Not very
> pretty. :-/
>
> Further, there may be a thin C++ layer that converts the error
> code and message to a C++ exception so that the C++ code need
> not deal with error codes. (I would definitely do this.)
>
> > Application will crash without any way to figure out where
> the D
> > exception was thrown.
>
> One solution for that is to log a stack trace at the point of
> exception construction. We used libunwind in a C++ project but
> I haven't done anything similar in D.
>
> Ali
Yes of course I mean unhandled exception handler.
Using try{}catch block of course possible if the function is
under you control.
But this will add a lot of repetitive code in every single even
small function.
This is also not possible to catch exceptions from something like
unittest blocks and especially init and finalization of D runtime.
In C++ code we really rarely throw any exception, most of the
time error codes are used and this work pretty well.
Any way right now it is only an experiment to test how well D2
will work together with C++ code base.
I do not want to switch from C++ (C++11) to D2 but use them
together.
Because some times D seems to be more expressive and powerful,
but then in other case it is too restrictive.
More information about the Digitalmars-d-learn
mailing list