[LLVMdev] RFC: Exception Handling Proposal Revised
John McCall
rjmccall at apple.com
Wed Dec 1 01:14:14 PST 2010
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.
John.
More information about the llvm-dev
mailing list