On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote:
> We need a libunwind expert to figure out a good approach for handling exceptions thrown by C++ code into D.
>
> Is anyone fluent with libunwind?
>
>
> Andrei

Is there plans to catching C++ exceptions in D?
What kind of C++ exceptions planned to catch in D?
For example C++ can throw primitive types exceptions, for example int.
Of cource, them can be wrapped into special D CPPException : Throwable, class, which contains string representation of C++ exception.
What about C++ polymorthic exceptions? AFAIK, C++ exception are throwing by-value, and catching by ref (to allow polimorthic catch). Where C++ calls destructor for exception? In catch block? In D GC handles an exception lifetime.
Is there any ideas about it?
P.S. I tell about user-side of catching C++ exceptions, not about implementation.

On 23 September 2014 23:44, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/23/14, 3:14 PM, Iain Buclaw via Digitalmars-d wrote:
>>
>> GDC lets foreign exceptions pass through just fine.
>
>
> Proper unwinding of the D stack and all? -- Andrei

If you mean in the sense that libunwind will happily work it's way up, bouncing between D / C++ stacks until it finds a catch handler, then yes.

Otherwise, please give an example.

Iain

On 23 September 2014 23:56, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/23/2014 3:45 PM, Andrei Alexandrescu wrote:
>>
>> On 9/23/14, 3:15 PM, Iain Buclaw via Digitalmars-d wrote:
>>>
>>> On 23 September 2014 22:29, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote:
>>>>>
>>>>>
>>>>> We need a libunwind expert to figure out a good approach for handling exceptions thrown by C++ code into D.
>>>>>
>>>>> Is anyone fluent with libunwind?
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>>
>>>>
>>>> https://github.com/deadalnix/libsdrt/blob/master/src/d/rt/eh.d
>>>
>>>
>>>
>>> https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/deh.d
>>>
>>>
>>> :o)
>>
>>
>> Noice. How difficult would be to port this to dmd/Linux? This is big - we
>> need
>> to get it done, and soon.
>>
>> Andrei
>
>
> There is a problem, that code is gpl licensed. It may not actually matter, since this code is only to interface with gpl libraries, but we should be careful.

As well as the license, there's also two technical details that need to be addressed to fit with the features of dmd EH.

1) Exception chaining - still on my todo
2) OOM exceptions could be handled better.

By all means, I'm happy with you to use it as a point of reference.

What you'll find is that pretty much all GCC frontend personality routines are essentially identical, barring the of handling it's own exception object / data.

Iain.

On 24 September 2014 12:27, IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote:
>>
>> We need a libunwind expert to figure out a good approach for handling exceptions thrown by C++ code into D.
>>
>> Is anyone fluent with libunwind?
>>
>>
>> Andrei
>
>
> Is there plans to catching C++ exceptions in D?

I'd say no to such an idea.

> What kind of C++ exceptions planned to catch in D?

None

> For example C++ can throw primitive types exceptions, for example int.
> Of cource, them can be wrapped into special D CPPException : Throwable,
> class, which contains string representation of C++ exception.
> What about C++ polymorthic exceptions? AFAIK, C++ exception are throwing
> by-value, and catching by ref (to allow polimorthic catch). Where C++ calls
> destructor for exception? In catch block? In D GC handles an exception
> lifetime.
> Is there any ideas about it?
> P.S. I tell about user-side of catching C++ exceptions, not about
> implementation.

Let C++ land catch the exception and deal with it.

Iain.

On 9/24/14, 5:06 AM, Iain Buclaw via Digitalmars-d wrote:
> On 23 September 2014 23:44, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 9/23/14, 3:14 PM, Iain Buclaw via Digitalmars-d wrote:
>>>
>>> GDC lets foreign exceptions pass through just fine.
>>
>>
>> Proper unwinding of the D stack and all? -- Andrei
>
> If you mean in the sense that libunwind will happily work it's way up,
> bouncing between D / C++ stacks until it finds a catch handler, then
> yes.

Yah, that's what I meant. Thanks! -- Andrei

On 9/24/14, 5:12 AM, Iain Buclaw via Digitalmars-d wrote:
> On 24 September 2014 12:27, IgorStepanov via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote:
>>>
>>> We need a libunwind expert to figure out a good approach for handling
>>> exceptions thrown by C++ code into D.
>>>
>>> Is anyone fluent with libunwind?
>>>
>>>
>>> Andrei
>>
>>
>> Is there plans to catching C++ exceptions in D?
>
> I'd say no to such an idea.

I understand the difficulty of it. However, we should look into it closely. Preventing D code from catching C++ exceptions forces one to implement the driver/event loop/etc in C++, which is quite unpleasant. It essentially takes C++ compatibility a few good notches down.

>> What kind of C++ exceptions planned to catch in D?
>
> None

I wonder how difficult would be to create a wrapper class CppException for everything derived from C++ std::exception. It would not save the exact exception, but it would save its what() string and perhaps the typeid().name(). A translator would create CppException objects from std::exception objects and their derivatives.

How hard would that be? Please advise.

>> For example C++ can throw primitive types exceptions, for example int.
>> Of cource, them can be wrapped into special D CPPException : Throwable,
>> class, which contains string representation of C++ exception.
>> What about C++ polymorthic exceptions? AFAIK, C++ exception are throwing
>> by-value, and catching by ref (to allow polimorthic catch). Where C++ calls
>> destructor for exception? In catch block? In D GC handles an exception
>> lifetime.
>> Is there any ideas about it?
>> P.S. I tell about user-side of catching C++ exceptions, not about
>> implementation.
>
> Let C++ land catch the exception and deal with it.

Believe me, I hear you :o). I'm afraid we need to do something better about it.


Andrei

On Wednesday, 24 September 2014 at 15:07:05 UTC, Andrei Alexandrescu wrote:
> On 9/24/14, 5:12 AM, Iain Buclaw via Digitalmars-d wrote:
>>>
>>> Is there plans to catching C++ exceptions in D?
>>
>> I'd say no to such an idea.
>
> I understand the difficulty of it. However, we should look into it closely. Preventing D code from catching C++ exceptions forces one to implement the driver/event loop/etc in C++, which is quite unpleasant. It essentially takes C++ compatibility a few good notches down.

If C++ code can execute D delegates, perhaps an intermediate step would be to create a wrapper in C++ that calls the delegate wrapped in an appropriate try/catch block.  Syntax would be a bit weird as you'd have to specify a callback for each exception type you wanted to catch, but it seems doable.

On 24 September 2014 16:07, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/24/14, 5:12 AM, Iain Buclaw via Digitalmars-d wrote:
>>
>> On 24 September 2014 12:27, IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Tuesday, 23 September 2014 at 17:37:42 UTC, Andrei Alexandrescu wrote:
>>>>
>>>>
>>>> We need a libunwind expert to figure out a good approach for handling exceptions thrown by C++ code into D.
>>>>
>>>> Is anyone fluent with libunwind?
>>>>
>>>>
>>>> Andrei
>>>
>>>
>>>
>>> Is there plans to catching C++ exceptions in D?
>>
>>
>> I'd say no to such an idea.
>
>
> I understand the difficulty of it. However, we should look into it closely. Preventing D code from catching C++ exceptions forces one to implement the driver/event loop/etc in C++, which is quite unpleasant. It essentially takes C++ compatibility a few good notches down.
>
>>> What kind of C++ exceptions planned to catch in D?
>>
>>
>> None
>
>
> I wonder how difficult would be to create a wrapper class CppException for everything derived from C++ std::exception. It would not save the exact exception, but it would save its what() string and perhaps the typeid().name(). A translator would create CppException objects from std::exception objects and their derivatives.
>
> How hard would that be? Please advise.
>

Thinking about it:

- Identifying a C++ exception, simple.

- Identifying whether a D catch handler for a C++ exception object matches, tricky - maybe.  ABI of structs being a potential maintenance burden - though you'd hope that they only change ABI once every two years or so. Second, determining that the C++ object being thrown and catch handler we are examining match might be awkward from D.  That is something that needs investigation.

However, for sure, the easiest thing that could be done *now* that only needs a slight EH library tweak is using catch-all handlers to recover from any language exception.

try {
  SomeCxxFuncThatMayThrow();
}
catch {
  // Recover, but without knowing what happened.
}

But I'd imagine you'd actually want information to come with your caught exception, though. :)

Iain

On 9/24/14, 9:05 AM, Sean Kelly wrote:
> On Wednesday, 24 September 2014 at 15:07:05 UTC, Andrei Alexandrescu wrote:
>> On 9/24/14, 5:12 AM, Iain Buclaw via Digitalmars-d wrote:
>>>>
>>>> Is there plans to catching C++ exceptions in D?
>>>
>>> I'd say no to such an idea.
>>
>> I understand the difficulty of it. However, we should look into it
>> closely. Preventing D code from catching C++ exceptions forces one to
>> implement the driver/event loop/etc in C++, which is quite unpleasant.
>> It essentially takes C++ compatibility a few good notches down.
>
> If C++ code can execute D delegates, perhaps an intermediate step would
> be to create a wrapper in C++ that calls the delegate wrapped in an
> appropriate try/catch block.  Syntax would be a bit weird as you'd have
> to specify a callback for each exception type you wanted to catch, but
> it seems doable.

That's a good idea, thanks. -- Andrei

On 9/24/14, 9:54 AM, Iain Buclaw via Digitalmars-d wrote:
> On 24 September 2014 16:07, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> I wonder how difficult would be to create a wrapper class CppException for
>> everything derived from C++ std::exception. It would not save the exact
>> exception, but it would save its what() string and perhaps the
>> typeid().name(). A translator would create CppException objects from
>> std::exception objects and their derivatives.
>>
>> How hard would that be? Please advise.
>>
>
> Thinking about it:
>
> - Identifying a C++ exception, simple.

Noice.

> - Identifying whether a D catch handler for a C++ exception object
> matches, tricky - maybe.  ABI of structs being a potential maintenance
> burden - though you'd hope that they only change ABI once every two
> years or so. Second, determining that the C++ object being thrown and
> catch handler we are examining match might be awkward from D.  That is
> something that needs investigation.

Yah. I'm thinking of simplifying assumptions, e.g. all C++ exceptions map to one single D type called CppException, and we can assume there's always a D handler on top of the stack. All the CppException saves is a copy of the what() message from the C++ exception.

> However, for sure, the easiest thing that could be done *now* that
> only needs a slight EH library tweak is using catch-all handlers to
> recover from any language exception.
>
> try {
>    SomeCxxFuncThatMayThrow();
> }
> catch {
>    // Recover, but without knowing what happened.
> }
>
> But I'd imagine you'd actually want information to come with your
> caught exception, though. :)

Well even a catch like that would definitely be an improvement.


Andrei