This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: catch(...) and forced unwind


>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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]