Throw from a destructor

[Phlip]

C++ers:

I have this friend who thinks C++ cannot throw from a destructor.

I think throwing from a destructor is bad Karma, and should be designed
around, but that C++ cannot strictly prevent the actual event.

(One compiler-oriented reason is a compiler might not be able to detect
that the call-tree from a destructor leads to a throw.)

Put another way, suppose I have a big object, aBigSimCity, and it has a
..shutdown() method. It must call before ~BigSimCity() calls, and it might
throw. This implies my Wrapper class, containing aBigSimCity, should never
declare a destructor like this: ~Wrapper() { aBigSimCity.shu tdown(); }.

..shutdown() might throw, and I don't feel like wrapping it in
try{}catch(). ~Wrapper should not throw, hence I need a better system to
break things down.

So which of us is right?

--
Phlip

[Marcus Kwok]

James Bannon <ja**********@n tlworld.comwrot e:

2. If, for some reason, your lucky enough not to have terminate
called, what do you do with the exception when you've caught it?
Re-throw if you can't recover? You're in terminate land. In any case,
how do you resuscitate or kill a partially dead object when you have
no way of knowing what state the object is in because that information
isn't conveyed to you by the exception class?

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.

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

However, most people don't use
throw specifications at all primarily because they're expensive at
runtime and sometimes they don't buy you very much in the way of
safety

http://www.gotw.ca/gotw/082.htm
seems to agree.

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

[James Bannon]

Marcus Kwok wrote:

James Bannon <ja**********@n tlworld.comwrot e:

>2. If, for some reason, your lucky enough not to have terminate
called, what do you do with the exception when you've caught it?
Re-throw if you can't recover? You're in terminate land. In any case,
how do you resuscitate or kill a partially dead object when you have
no way of knowing what state the object is in because that information
isn't conveyed to you by the exception class?

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.

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

> However, most people don't use
throw specifications at all primarily because they're expensive at
runtime and sometimes they don't buy you very much in the way of
safety

http://www.gotw.ca/gotw/082.htm
seems to agree.

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.

Jim.

[red floyd]

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

[James Bannon]

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. :)

Jim.

[Jim Langston]

"James Bannon" <ja**********@n tlworld.comwrot e in message
news:ji******** ***********@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.

[Phlip]

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]

Jim Langston wrote:

"James Bannon" <ja**********@n tlworld.comwrot e in message
news:ji******** ***********@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]

>James Bannon <ja**********@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 <ja**********@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