This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3] Followup to C++ forced unwinding
- From: Mike Harrold <mharrold at cas dot org>
- To: fjh at cs dot mu dot OZ dot AU (Fergus Henderson)
- Cc: gdr at integrable-solutions dot net (Gabriel Dos Reis), mark at codesourcery dot com (Mark Mitchell), rth at redhat dot com (Richard Henderson), ncm at cantrip dot org (Nathan Myers), drepper at redhat dot com (Ulrich Drepper), gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Fri, 2 May 2003 11:31:54 -0400 (EDT)
- Subject: Re: [3.3] Followup to C++ forced unwinding
>
> On 02-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> > Mark Mitchell <mark@codesourcery.com> writes:
> > [...]
> > | But we shouldn't go silently breaking millions of lines of until-now
> > | exception-safe ISO-conformant code that happens to use "catch(...)"
> > | rather than destructors. I'd ever so much rather debug a
> > | why-didn't-my-thread-go-away bug than a
> > | why-is-my-data-in-an-inconsistent-state bug.
> >
> > strongly seconded.
>
> I agree that ignoring "catch(...)" handlers for cancels is not going to fly.
> I agree about which bug I'd prefer to debug.
>
> But my intuition is that I think that very few of those million lines
> of until-now exception-safe ISO-conformant code would break from an
> implicit rethrow if/when a cancel got swallowed -- I think a lot more
> would break from an implicit terminate() in the same situation.
But only if the implicit rethrow happens when a cancellation exception has
been caught in the catch (...) block. Other exceptions _must_ be allowed
to fall off the end of the block...
Regards,
/Mike