catch(...) and forced unwind

Nathan Myers ncm@cantrip.org
Sat Dec 13 09:26:00 GMT 2003


[apologies to those seeing this twice -- mailing list trouble.]
On Sat, Dec 13, 2003 at 01:54:55AM -0500, Jason Merrill wrote:
> On Fri, 12 Dec 2003 18:37:54 -0600, Benjamin Kosnik <bkoz@redhat.com> wrote:
> 
> >>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 
> >[...]
> > Ie, a __cancellation_handler that could be set to either rethrow,
> > continue, or abort?
> 
> That seems plausible to me.  I think that #2 would still be appropriate.

I suggested the distinct handler the last time this was discussed, and 
the only comments on it were in agreement.

The point is that a program would be equipped to enforce 
standard-conforming behavior.  Just as now every C++ program that 
uses cin and/or cout where performance matters starts with a call 
"std::ios::sync_with_stdio(false);", every threaded program where 
correctness matters would need to start with a call to fix the 
cancellation handler, to behave in the way that well-written
libraries expect (and, therefore, require):

  int main()
  {
    std::ios:sync_with_stdio(false);
#   ifdef __GLIBC__  /* or some damn thing */
      __gnu::set_cancellation(__gnu::__continue_cancellation);
#   endif
  ...

It would stink, but would beat being unable to ship a program that has 
documentable behavior.  I would prefer to put that call in the static
init code for libstdc++.  Of course the best approach would be to 
leave exception semantics the hell alone; a patchable handler amounts
to damage control.

For an iostream exception handler, it would be fine for it to set 
badbit and return, when a cancellation exception occurred.  The next 
cancellation exception wouldn't be in iostream code any more, because 
the stream active when the cancellation occurred would be no longer 
usable, and good code already handles finding badbit set.

Nathan Myers
ncm-nospam@cantrip.org



More information about the Gcc mailing list