Hello,


We are racking our brains to figure out what to do about exceptions thrown from C++ functions into D code that calls them.

A few levels of Nirvana would go like this:

0. Undefined behavior - the only advantage to this is we're there already with no work :o).

1. C++ exceptions may be caught only by C++ code on the call stack; D code does the stack unwinding appropriately (dtors, scope statements) but can't catch stuff.

2. D code can catch exceptions from C++ (e.g. via a CppException wrapper class) and give some info on them, e.g. the what() string if any.

Making any progress on this is likely to be hard work, so any idea that structures and simplifies the design space would be welcome.


Andrei

On Friday, 12 September 2014 at 00:34:52 UTC, Andrei Alexandrescu wrote:
> Making any progress on this is likely to be hard work, so any idea that structures and simplifies the design space would be welcome.

Just a quick comment on this: 2) is very simple to implement for all the compilers that actually use libunwind Dwarf 2 EH on Linux, i.e. GDC and LDC (I think deadalnix already looked into this for SDC).

3) is also doable, but of course significantly more annoying because you need to deal with the internals of the exception ABI of your C++ compiler. Accessing the exception object is relatively trivial, ABI and mangling support is slowly coming anyway, but OTOH handling the exception lifetime correctly could become somewhat of a headache.

David

On Friday, 12 September 2014 at 00:44:10 UTC, David Nadlinger wrote:
> 2) […] 3)

Aaand of course I missed the fact that your list in fact started at 0.

On Friday, 12 September 2014 at 00:34:52 UTC, Andrei Alexandrescu wrote:
> Hello,
>
>
> We are racking our brains to figure out what to do about exceptions thrown from C++ functions into D code that calls them.
>
> A few levels of Nirvana would go like this:
>
> 0. Undefined behavior - the only advantage to this is we're there already with no work :o).
>
> 1. C++ exceptions may be caught only by C++ code on the call stack; D code does the stack unwinding appropriately (dtors, scope statements) but can't catch stuff.
>

This is what SDC does.

> 2. D code can catch exceptions from C++ (e.g. via a CppException wrapper class) and give some info on them, e.g. the what() string if any.
>

This would require that druntime to be dependent on C++ runtime.

On Friday, 12 September 2014 at 00:44:10 UTC, David Nadlinger wrote:
> 3) is also doable, but of course significantly more annoying because you need to deal with the internals of the exception ABI of your C++ compiler. Accessing the exception object is relatively trivial, ABI and mangling support is slowly coming anyway, but OTOH handling the exception lifetime correctly could become somewhat of a headache.
>

Yes, that is pretty why I limited myself to the "unwind properly but do not catch" option. This one would require to mess with the innards of various C++ runtime.

On Friday, 12 September 2014 at 00:34:52 UTC, Andrei Alexandrescu wrote:
>
> We are racking our brains to figure out what to do about exceptions thrown from C++ functions into D code that calls them.

Allowing a C++ exception to propagate through D code is definitely possible.  Catching a C++ exception would require some knowledge of how that particular C++ runtime throws exceptions though.  Like I can see registering an exception handler for a C++ exception maybe somewhat similar to SEH, then prettying it up with syntactic sugar.  It seems tricky but doable, at least at a glance.

On 12 Sep 2014 01:35, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> Hello,
>
>
> We are racking our brains to figure out what to do about exceptions
thrown from C++ functions into D code that calls them.
>
> A few levels of Nirvana would go like this:
>
> 0. Undefined behavior - the only advantage to this is we're there already
with no work :o).
>
> 1. C++ exceptions may be caught only by C++ code on the call stack; D
code does the stack unwinding appropriately (dtors, scope statements) but
can't catch stuff.
>

Libunwind + handling foreign exceptions you can do this.  And is beneficial in that it works with any other languages that use libunwind, such as gccgo.

Iain

On 12/09/14 02:35, Andrei Alexandrescu wrote:
> Hello,
>
>
> We are racking our brains to figure out what to do about exceptions
> thrown from C++ functions into D code that calls them.
>
> A few levels of Nirvana would go like this:
>
> 0. Undefined behavior - the only advantage to this is we're there
> already with no work :o).
>
> 1. C++ exceptions may be caught only by C++ code on the call stack; D
> code does the stack unwinding appropriately (dtors, scope statements)
> but can't catch stuff.
>
> 2. D code can catch exceptions from C++ (e.g. via a CppException wrapper
> class) and give some info on them, e.g. the what() string if any.
>
> Making any progress on this is likely to be hard work, so any idea that
> structures and simplifies the design space would be welcome.

1 and 2 would really be a help for the D/Objective-C integration as well since on 64bit is uses the same exception model as C++.

-- 
/Jacob Carlborg

On 12/09/14 02:44, David Nadlinger wrote:

> Just a quick comment on this: 2) is very simple to implement for all the
> compilers that actually use libunwind Dwarf 2 EH on Linux, i.e. GDC and
> LDC (I think deadalnix already looked into this for SDC).

It would be nice if DMD could do the same for D exceptions.

> 3) is also doable, but of course significantly more annoying because you
> need to deal with the internals of the exception ABI of your C++
> compiler. Accessing the exception object is relatively trivial, ABI and
> mangling support is slowly coming anyway, but OTOH handling the
> exception lifetime correctly could become somewhat of a headache.

Is handling the exception any more of a headache compared to only using C++?

-- 
/Jacob Carlborg

On 12/09/14 05:25, deadalnix wrote:

> Yes, that is pretty why I limited myself to the "unwind properly but do
> not catch" option. This one would require to mess with the innards of
> various C++ runtime.

On 64bit Objective-C can catch C++ exceptions. But I don't think you can do anything with the exception, i.e. it uses the following catch syntax:

@catch(...) {}

Would that be easier?

-- 
/Jacob Carlborg