This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: catch(...) and forced unwind
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, rth at redhat dot com, mark at codesourcery dot com, drepper at redhat dot com, jakub at redhat dot com, ncm at cantrip dot org, dave at boost-consulting dot com, wekempf at cox dot net, fjh at cs dot mu dot oz dot au, jason at redhat dot com
- Date: Fri, 12 Dec 2003 18:37:54 -0600
- Subject: Re: catch(...) and forced unwind
- Organization: Red Hat / Chicago
- References: <xypwu91ofvf.fsf@miranda.boston.redhat.com>
>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