catch(...) and forced unwind

Benjamin Kosnik bkoz@redhat.com
Sat Dec 13 02:22:00 GMT 2003


>I see three ways to fix this:
>
>1) automatically rethrow cancellation.
>2) explicitly rethrow cancellation--this would require some way to catch it
>   specifically, but we really ought to have that anyway.

What about 

  typedef void (*__cancellation_handler)();
  __cancellation_handler __set_cancellation(__cancellation_handler  f ) throw();
  void __cancellation();

Ie, not overloading terminate and just calling a spade a spade, and
inventing new bits to take care of this without overloading the meaning
of terminate or confusing the issue, in the same familiar way that
terminate is handled?

Then people could use __set_cancellation above with these new functions:

void __abort_cancellation() { std::abort }

void __rethrow_cancellation() { __throw_exception_again; }
 
void __continue_cancellation() { }

Ie, a __cancellation_handler that could be set to either rethrow,
continue, or abort? I think a user-configurable solution is really the
only solution that is going to get any traction.

>3) don't catch and swallow all exceptions; changing the catch(...) to
>   catch(std::exception) would catch all exceptions thrown by other parts
>   of the library, which AFAIK is what we're trying to accomplish.

I would dearly love to do this, and this is the way v3 originally
implemented these catch clauses. I think this is really the correct
behavior for iostreams. However, this violates both exisiting code and
the current text of the standard, so I think it's a non-starter.

-benjamin 



More information about the Gcc mailing list