[LLVMdev] RFC: Exception Handling Proposal II

John McCall rjmccall at apple.com
Sun Nov 28 15:53:24 PST 2010


On Nov 28, 2010, at 9:50 AM, Duncan Sands wrote:
>>> In Ada you can throw and exception inside a destructor and it does not lead
>>> to program termination.
>> 
>> Interesting.  I assume that the personality still sees these as just cleanups,
>> so this must be implemented by running the destructor in a handler which
>> aborts both unwinds and throws the Program_Error?
> 
> Right.  The dwarf exception library doesn't mind if you throw a new exception
> inside a cleanup, it just unwinds it.  ["Cleanups don't throw" is a C++ specific
> concept that is built on top of the basic unwinder facilities; gcc does it by
> wrapping cleanup code in a no-throw filter, either explicitly or implicitly via
> no-throw regions, which are an optimization but conceptually no different to a
> no-throw filter].

Right.  In clang (and llvm-gcc, I think) we generate a catch-all which just calls
terminate.

> So the Ada stuff can just wrap the running of destructors in
> a catch-all, and if a destructor throws it then finalizes the original
> exception (finalizing exceptions never throws in Ada) and throws a new one
> (Program_Error) instead, which then unwinds in the usual way, which may mean
> being caught in the containing function if the scope being left is wrapped in
> one which catches Program_Error.  Of course this means that in LLVM it would be
> wrong to bake in a rule like "cleanup code never throws", but hopefully no-one
> was suggesting that.

I had actually thought of something like that at one point, in an effort to document
the expectation of the unwinder, but I'm totally willing to change it to "cleanup code
that throws or returns is responsible for aborting the current unwind".

> PS: If you and Bill came to a consensus over the definition of regions etc,
> it would be nice to see a revised proposal from Bill that incorporates it.

I'm not sure if there's a consensus yet.

John.



More information about the llvm-dev mailing list