September 24, 2014
On Wednesday, 24 September 2014 at 19:28:50 UTC, Andrei
Alexandrescu wrote:
>> 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.
>

Considered it for SDC. it is not that simple as if it is a C++
exception, you need to do the same cleanup of the exception that
the C++ runtime would do, which is not that simple.
September 24, 2014
On 24 September 2014 21:11, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 24 September 2014 at 19:28:50 UTC, Andrei Alexandrescu wrote:
>>>
>>> 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.
>>
>
> Considered it for SDC. it is not that simple as if it is a C++ exception, you need to do the same cleanup of the exception that the C++ runtime would do, which is not that simple.

Hmm... I forgot about the C++ compiler emitting function calls for the begin/end of catches.  Yeah, that would indeed need to be supported on the compiler side!
September 24, 2014
On Wednesday, 24 September 2014 at 19:28:50 UTC, Andrei
Alexandrescu wrote:
> 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

I have one freaky example for you. This example can be
non-standart and danger but it works:
C++ side: http://pastebin.ru/PceYCOEq
special function catch exception, pass it to specified handler
and re-throw, if handler not found

D side: http://pastebin.ru/7FNBzXHw
D defines a special handler and pass it to catchException
result:
D code call C++ function

void throwEx(void *)
{
     throw 4;
}
and prints:
dside.CPPException!int.CPPException@(0): 4

Doesn't fire to me, please :)
September 24, 2014
Now DMD doesn't support thorowing C++ exceptions through D function:

extern(C++)
void throwEx(); //compiled by G++ and throws exception

extern(C++)
void dFunc(void*)
{
   throwEx();
}


catchException(&dFunc, ...); //terminate programm instead of catch it. Should be works in gdc

September 24, 2014
On 9/24/14, 2:53 PM, IgorStepanov wrote:
>
> I have one freaky example for you. This example can be
> non-standart and danger but it works:
> C++ side: http://pastebin.ru/PceYCOEq
> special function catch exception, pass it to specified handler
> and re-throw, if handler not found
>
> D side: http://pastebin.ru/7FNBzXHw
> D defines a special handler and pass it to catchException
> result:
> D code call C++ function
>
> void throwEx(void *)
> {
>       throw 4;
> }
> and prints:
> dside.CPPException!int.CPPException@(0): 4
>
> Doesn't fire to me, please :)

Awesome! How do we make it standard and safe? -- Andrei
September 24, 2014
On Wednesday, 24 September 2014 at 22:14:5 UTC, Andrei
Alexandrescu wrote:
> On 9/24/14, 2:53 PM, IgorStepanov wrote:
>>
>> I have one freaky example for you. This example can be
>> non-standart and danger but it works:
>> C++ side: http://pastebin.ru/PceYCOEq
>> special function catch exception, pass it to specified handler
>> and re-throw, if handler not found
>>
>> D side: http://pastebin.ru/7FNBzXHw
>> D defines a special handler and pass it to catchException
>> result:
>> D code call C++ function
>>
>> void throwEx(void *)
>> {
>>      throw 4;
>> }
>> and prints:
>> dside.CPPException!int.CPPException@(0): 4
>>
>> Doesn't fire to me, please :)
>
> Awesome! How do we make it standard and safe? -- Andrei
C++ hasn't standart abi(
If we talk about g++, this code has a one conspicuous trouble: I
don't know, how to correctly get a pointer to exception. Class
exception_ptr has getter for it, but it is private. I'll think
about another variants.
And I don't know about <cxxabi.h> standartness.
The second trouble: if we want to do something more exception
printing, we should get an exception pointer to user. However,
user shouldn't copy this pointer, because exception object will
be destroyed in cpp side.
Good news: this code (D side) can be generated by D compiler:
try
{
     // C++ exceptions danger
}
catch(CPPException!int e)
{
}
catch(CPPException!myException e)
{
}

Of course, only exact match of exception will be works. No
polymorphism.
September 25, 2014
On Wednesday, 24 September 2014 at 15:07:05 UTC, Andrei Alexandrescu wrote:
> I wonder how difficult would be to create a wrapper class CppException for everything derived from C++ std::exception.

Why not catch std::exception directly? Then you could generate code, just like C++ compiler does it.
September 25, 2014
On 9/25/14, 4:55 AM, Kagamin wrote:
> On Wednesday, 24 September 2014 at 15:07:05 UTC, Andrei Alexandrescu wrote:
>> I wonder how difficult would be to create a wrapper class CppException
>> for everything derived from C++ std::exception.
>
> Why not catch std::exception directly? Then you could generate code,
> just like C++ compiler does it.

That would be a language change - right now D can only catch Exception objects.

Andrei

September 25, 2014
On Thursday, 25 September 2014 at 13:58:23 UTC, Andrei Alexandrescu wrote:
> That would be a language change - right now D can only catch Exception objects.

Isn't the idea to let D do more things with C++ things?
September 25, 2014
I mean, D's inability to interoperate with C++ is not a feature, but a problem meant to be solved as long as it doesn't take too much effort.