Use C++ exception model in D

[Michel Fortin]

On 2014-04-09 17:27:55 +0000, "David Nadlinger" <code at klickverbot.at> said:

> On Wednesday, 9 April 2014 at 16:48:54 UTC, Jacob Carlborg wrote:
>> x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC and GDC 
>> all used the same exception handling model and the same as C++ it would 
>> be easier. Especially for implementing support for Objective-C 
>> exceptions, which is why initially started this thread.
> 
> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom 
> EH implementation.
> 
> With GDC and LDC, you'd just need to add your code to handle 
> Objective-C exceptions to the personality functions. libunwind 
> exceptions have a "type"/"source language" field, and by default most 
> implementations either ignore unknown exception types or abort on 
> encountering them.

Maybe the right course of action would be to just ignore Objective-C 
exceptions in 64-bit DMD and finish the rest of D/Objective-C. The day 
D/Objective-C is ported to GDC and LDC, it should be much easier to 
make exceptions work there.

The funny thing is that within Cocoa exceptions are usually reserved 
for logic errors (array out of bound, method calls with unknown 
selector, assertion errors, etc.). That's the kind of error we consider 
unrecoverable when they happen in D code. So I think people can manage 
without Objective-C exceptions for some time.

Given what I wrote above, I'll also argue that it's not a wise move to 
support exceptions in D/Objective-C with the legacy runtime even though 
I implemented it. Because the legacy runtime uses setjmp/longjmp for 
exceptions, try blocks in a function that calls extern(Objective-C) 
functions are costly. And the compiler has to implicitly add those 
costly try blocks to wrap/unwrap exception objects to prevent unwinding 
of the wrong kind from leaving the current function. It was fun to 
implement, but it's also the most intrusive changes D/Objective-C makes 
to the frontend, and a big parts of the additions to druntime.

If we plan to support mixed unwind mechanisms some day it might be 
useful to keep, because the logic for bridging between two or more 
unwinding systems is all there. Otherwise I'd probably scrap the whole 
exception wrapping/unwrapping thing. I doubt the performance cost is 
worth it, and I doubt the maintenance cost for the additional 
complexity is worth it. The legacy Objective-C runtime is mostly gone 
from Apple's ecosystem anyway.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca