[LLVMdev] RFC: Exception Handling Proposal Revised

[John McCall]

On Dec 1, 2010, at 1:48 AM, Bill Wendling wrote:

> On Dec 1, 2010, at 1:14 AM, John McCall wrote:
> 
>> On Dec 1, 2010, at 12:55 AM, Sebastian Redl wrote:
>> 
>>> On 01.12.2010 09:25, John McCall wrote:
>>>> 
>>>> One problem I foresee is that it's possible for a dispatch block to become unreachable from its landing pad.  If that block is then deleted, we'd lose information about what's supposed to unwind there.  This could happen if, e.g., someone had a noreturn destructor.  In languages that usefully allow throws from EH destructors (i.e. Ada) I can imagine uses for this, and regardless it's well-formed code that shouldn't cause the world to explode.
>>> The way I understood Duncan's description of the Ada model, even an 
>>> unconditionally throwing Ada constructor isn't exactly noreturn - or 
>>> rather, every destructor is surrounded by its own try-catch.
>>> Same in D, btw, which also allows throwing destructors. There, a throw 
>>> with an in-flight exception appends the new exception to the in-flight 
>>> chain of exceptions and keeps unwinding.
>> 
>> I'm not sure why this isn't supposed to be equivalent to noreturn;  the point is that the normal edge of the function isn't reachable.  I mentioned Ada EH just because it's more obviously useful there, not because it's a special case that can only occur there.  For example, you could duplicate this with a destructor that runs an infinite loop or calls exit().  The representation needs to be robust against this.
>> 
> Fair enough. Do you think it would be sufficient to refuse to delete a dispatch instruction unless the landing pad is also deleted? (That's just off the top o' my head...)

That might be annoying to enforce.  On the other hand, it might be less annoying than anything we could do with the landingpad attribute.

John.