Use C++ exception model in D

[Iain Buclaw]

On 9 April 2014 08:19, Jacob Carlborg <doob at me.com> wrote:
> On 08/04/14 14:03, David Nadlinger wrote:
>>
>> On Tuesday, 8 April 2014 at 10:08:24 UTC, Jacob Carlborg wrote:
>>>
>>> Is there a reason to not use the same model, or what's required to be
>>> compatible?
>>
>>
>> In short, the reason not to use the same "model" (you could argue that
>> the model is the same, as only the personality functions differ) is that
>> the exception unwinder is intimately tied to both the target language
>> ABI and semantics.
>>
>> For example, all unwinders need to handle the run-time type information
>> for the exception object to correctly dispatch it. And while e.g. the
>> GNU C++ unwinding implementation needs to pull shenanigans to implement
>> the crazy C++ exception lifetime model (cf. catching by reference vs. by
>> value) and enforce throws(...) specifications, the D unwinder needs to
>> understand the difference between Exception and Error and correctly
>> implement exception chaining.
>>
>> Now, of course, it is possible to find a middle ground that works as a
>> basis for virtually all languages. In fact, I'd argue that SEH for
>> Windows actually provides such a layer, and libunwind does too. For
>> example, a proper implementation of a libunwind personality function
>> allows you to check whether a given exception originated in your own
>> language, and just pass it on otherwise (such that e.g. C++ exception
>> just bubble through a layer of D code). In theory, it would e.g. also be
>> possible to wrap foreign exceptions in e.g. D Throwable objects to make
>> them catchable in D code. But the lifetime of the foreign object is
>> virtually impossible to get right in the general case, and the benefits
>> of wrapping exceptions like this have turned out not to be worth it,
>> because it is hard to handle them in a sensible way in the receiving
>> language (DMD actually does - did? - something like this on Win32).
>
>
> A middle ground would help. In the D/Objective-C implementation there is
> already an exception bridge for 32bit. The 32bit implementation uses setjmp
> and longjmp.
>

The "middle-ground" would be us handling Objective-C foreign
exceptions in our EH personality function.