From 5828488275697204143
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,96a8c01f7043c2d9
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2002-08-30 20:55:02 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!news-out.cwix.com!newsfeed.cwix.com!news.alt.net!comp-std-cpp-robomod!not-for-mail
From: "Garry Lancaster" <glancaster@ntlworld.com>
Newsgroups: comp.std.c++
Subject: Re: Proposal: exception stack unwinding resumption
Date: 31 Aug 2002 03:55:01 GMT
Organization: ntlworld News Service
Lines: 62
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <zllb9.458$S51.25977@newsfep1-gui.server.ntli.net>
References: <6df0c6a8.0208260746.633710cb@posting.google.com>
Return-Path: <devnull@stump.algebra.com>
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
Delivered-To: std-c++@ncar.ucar.edu
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Complaints-To: abuse@ntlworld.com
X-Trace: newsfep1-gui.server.ntli.net 1030611423 213.105.168.132 (Thu, 29 Aug 2002 09:57:03 BST)
NNTP-Posting-Date: Thu, 29 Aug 2002 09:57:03 BST
Xref: archiver1.google.com comp.std.c++:13510

Pierre Baillargeon:
> When a non-catched exception is thrown in the destructor of an object
> during stack unwinding, the current standard requires the following
> behavior. The C++ run-time somehow checks if an exception handler can
> be found to catch the exception upto the destructor call made by the
> stack-unwinding. If one is found, the exception is catched as always.
> If none is found (i.e. the destuctor exit via an excption),
> terminate() is called.
>
> What I propose is that this last behavior be selectable. A function,
> with the signature bool set_unwinding_resumption(bool), would allow
> toggling between the current behavior and a new one: that the
> unhandled exception that exited the destructor be thrown-away (no pun
> intended) and that stack unwinding resume as if teh destructor had
> exited normally. It would return the previous setting.

You can already get close to the behaviour you want
by swallowing exceptions in your destructors if
std::uncaught_exception() is true e.g.

foo::~foo() {
    try {
        // Code that might throw...
    } catch(...) {
        if( !std::uncaught_exception() ) throw;
    }
}

(However, item 19 in Herb Sutter's "More Exceptional
C++" explains why this can sometimes generate false
positives. If you don't have the book the problem is
shown by:

bar::~bar() {
    try {
        foo f;
        // whatever.
    } catch(...) {
        // whatever.
        if( !std::uncaught_exception() ) throw;
    }
}

If a bar is destroyed during stack unwinding, f's
destructor will never throw, even though it is safe
to do so.)

I don't think the proposal adds enough to what we
already have to warrant its inclusion in the language.

Kind regards

Garry Lancaster
Codemill Ltd
Visit our web site at http://www.codemill.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]