Throw from a destructor

[Phlip]

Re: Throw from a destructor

Noah Roberts wrote:

It is impossible to write exception safe code if any destructor can
throw. Destructors must therefore ALWAYS have the no-throw guarantee.
If this means having catch(...) then so be it...never allow exceptions
to escape a destructor...ne ver.

Thanks guys. Here's why I asked the question.

Some C++ test rigs support an explicit setUp() and tearDown() for their test
fixtures.

Some (despite being written by authors of books on C++) only provide the
constructor and destructor of the fixture.

I had to make a case for always providing tearDown(). For example, my
current project must call orb->shutdown() after each test case, and that
might throw. I need the throw reliably caught, without impossible
ramifications.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[James Bannon]

Re: Throw from a destructor

Jim Langston wrote:

"James Bannon" <james.bannon@n tlworld.comwrot e in message
news:jiBtg.4349 2$Z61.29849@new sfe4-win.ntli.net...

>red floyd wrote:

>>James Bannon wrote:
>>>For instance I still can't find the specific definition of the term
>>>POD. I know what a POD is (roughly) but I can't find a specific
>>>definition in the Standard other than a note to say that the acronym POD
>>>stands for "Plain Old Data".
>>See 3.9/10 and 9/4

>Thanks red,
>I have it! 9/4 is interesting as an English example of a self-referential
>definition. :)

>
Really? I'd like to read it but don't have the standard. Is it something
like the definition of recursion?
>
Recursion: See recursion.
>
>

Something like that except it's of the form POD: see non-POD.

The wording I have is:

"...A POD-struct is an aggregate class that has no non-static data members of type
non-POD-struct, non-POD-union (or arrays of such types) or reference, and has no
user-defined copy assignment operator and no user-defined destructor...."

Hmmm.... clear enough? :)

Jim.

[Marcus Kwok]

Re: Throw from a destructor

>James Bannon <james.bannon@n tlworld.comwrot e:

>>Sutter and others advise writing destructors as if they had an empty
>>throw specification. That's good enough for me! If you do specify it,
>>say ~T() throw() {...}, at least if an exception is leaked then
>>terminate will be called immediately.

Marcus Kwok wrote:

>Actually, it will call unexpected(), which I believe by default will
>call terminate(), but this behavior can be overridden with
>std::set_unexp ected().

James Bannon <james.bannon@n tlworld.comwrot e:

You're right of course, it does call unexpected() which, if not
redefined, will call terminate. But what can you do within
std::set_unexpe cted() if a destructor unexpectedly throws? By the time
it gets to the unexpected handler you've no way of knowing which
destructor caused the problem, so you might as well terminate anyway
although it might be a bit more graceful that a core dump.

Well, unexpected() seems to be pretty limited.

http://www.gotw.ca/gotw/082.htm basically says you can either 1)
translate the exception into something allowed by the exception
specification, or 2) call terminate(). But IIRC if a destructor throws
an exception in the process of stack unwinding, then terminate() gets
called immediately, the rationale being that if there are two active
exceptions, it is undetermined which one should get priority, so the
program just dies.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply