On 23 November 2015 at 19:18, Walter Bright via Digitalmars-d < [email protected]> wrote:
> On 11/23/2015 10:07 AM, Iain Buclaw via Digitalmars-d wrote: > >> Yes, the _d_dynamic_cast is redundant. This happened because the EH >> pointer was >> treated as an Object, then upcasted to the catch type via the normal >> convert() >> routines. This is what caused the unnecessary call to _d_dynamic_cast. >> >> This switch statement is generated by GCC itself, and it tries to be >> accommodating for all supported languages. I imagine that the default >> case is >> there to support `catch(...)` in C++ code, however D has no notion of this >> construct, so what is instead generated is _Unwind_Resume to tell unwind >> to keep >> looking up the call chain. >> >> In other words, the default case should never really happen in D code >> except in >> the event of a logic bug in the unwind EH personality function (or >> possibly >> corruption). If you feel it more appropriate, I don't see the harm in >> replacing >> it with whatever HLT or abort instruction you like. :-) >> > > Thanks, this helps a lot, and makes me a lot more comfortable with the > notion that I understand what is going on. I won't generate the cast, then, > and I'll use a HLT for the default. > > BTW, are you working on supporting catching std::exception ? > > My eevil plan is to get D exceptions working completely before trying to > support std::exception. > Actively? No. First comes 2.067, which will have to be updated *as is* without the visitor conversions. I will need to adjust *my* personality function to be more graceful for handling foreign exceptions. After that, I can look into C++ typeinfo mangling. It's just normal C++ mangling with a _ZT prefix, no? :-) Also, I notice that you are using an older version of GDC. That version you're using doesn't support exception chaining. To get that working I had to invent a callback __gdc_begin_catch() which cleans up the chained exceptions list.
