On Friday, 12 September 2014 at 22:50:50 UTC, Sean Kelly wrote:
> I'm hoping it's simply a matter of sticking the right data in a
> lookup table and letting the C++ runtime figure out what the
> proper match is for us.

I suggest familiarizing yourself with how libunwind works. Look up personality routines, or even just peruse GCC's libstdc++-v3/libsupc++/eh_personality.cc or Clang's libcxxabi/src/cxa_{exception, personality}.cpp.

> D currently has a custom mechanism for throwing on non-Windows
> platforms, but it may be worth switching to the established C++
> approach, provided we can do so without losing anything (and this is a big "if" given how we implicitly chain exceptions).

s/D/DMD/. And yes, LDC does implement exception chaining.

On Friday, 12 September 2014 at 06:56:29 UTC, Jacob Carlborg
wrote:
> 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?

Yes, but still require the D runtime to interface with the C++
runtime, in order to restore the proper context.

On Friday, 12 September 2014 at 17:57:41 UTC, Marc Schütz wrote:
> How about
>
>     try {
>         my_cpp_func();
>     } catch(CppException!(const(char)*) e) {
>         writeln(e.payload.fromStringz());
>     }
>
> ?
>
> Btw, how does implicit conversion work with `catch` in C++? I.e., if you throw a `char*`, will it be caught when you catch `const char*`? This can not be handled easily with such a template, as we would need to catch both `CppException!(const(char)*)` and `CppException!(char*)`.

This is really WAY harder that it seems.

First, you got to understand C++'s RTTI so you can generate the
correct code to match catch blocks. That mean the D compiler must
be able to generate the RTTI symbols for them to link.

Then you got to implement the runtime part of it, considering
there is absolutely NO standardization at all, it is 100%
dependent on implementations details of the C++ standard lib you
are using. You got to retrieve the exception from an opaque
pointer on a structure that is compiler/stdlib dependent and make
sense of it. Then you got to understand the C++ RTTI information
do the proper matching of C++ exceptions with catch blocks's type.

Finally, you have to interface with the C++ runtime to do the
proper call in order to make the C++ runtime aware of what D's
doing. This part is more standardized, so that should be easier.