I have a question about the intended use of exceptions.

For some time I have been designing classes that throw
exceptions from a constructor. This helps to catch
problems with the allocation of resources. Recently
I have been working on a class which needs to make
sure that a system resource has been restored to a
previous state when the object (that changed the
resource on creation) is destroyed. If, for some
reason, the resource could not be restored to its
previous state, I throw an exception. However, I
see a potential problem with this: if the destructor
throws an exception, the destructor does not complete
and the object is not destroyed (unless I attempt to
fix the problem and try to destroy it again in the
future). This could lead to a memory leak.

I know it's *legal* to throw an exception from a
destructor but my question is: is it acceptable to
throw an exception from a destructor or not?
I'd like to hear comments pro and con.

Here is a pared down example:

class A {
public:
    class Err {};
    A() { /* change a resource */ }
    ~A() { if( f() == -1) throw Err; }
    // f() is some library function that
    // ... returns -1 if some error occurs
};


Thanks in advance:

Kevin Bowman
Software Engineer

Integral Vision, A Division of Medar, Inc.
E-Mail: kbowman@medar.com
Web: www.medar.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I don't have a copy of the proposed standard, so this may not still be
true, but p.364 of the Annotated C++... says terminate() will be called
when a destructor is called during stack unwinding caused by an exception
tries to exit using an exception.

Which I think means that if a destructor throws an exception it will call
terminate(). This may or may not be what you would like to happen.  Most of
the code I write tries to account for failing to allocate a resource, and
if a resource is found to be in an invalid state, throws it away, or fixes
it on the spot. Then continues as best it can. After all the next pass may
have enough system resources to acquire the resource.

-Gary-
(Just remove the spam from my address.)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 03 Oct 97 09:27:05 GMT, "Kevin J. Bowman" <kbowman@medar.com>
wrote:

>I know it's *legal* to throw an exception from a
>destructor but my question is: is it acceptable to
>throw an exception from a destructor or not?
>I'd like to hear comments pro and con.

There have been several discussions about this in various C++
newsgroups in recent months. Most that I recall ended with the
majority agreeing that throwing exceptions from destructors is a bad
idea. A DejaNews search would probably turn up something.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

    Check out uncaught_exception().

You best not throw in a destructor if the invocation of the destructor
itself is caused by an exception.

Jowell Hanson jkhanson@ix.netcom.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Gary Powell" <gary.powell@nospam.sierra.com> writes:

 |> I don't have a copy of the proposed standard, so this may not still be
 |> true, but p.364 of the Annotated C++... says terminate() will be called
 |> when a destructor is called during stack unwinding caused by an exception
 |> tries to exit using an exception.
 |>
 |> Which I think means that if a destructor throws an exception it will call
 |> terminate(). This may or may not be what you would like to happen.  Most of
 |> the code I write tries to account for failing to allocate a resource, and
 |> if a resource is found to be in an invalid state, throws it away, or fixes
 |> it on the spot. Then continues as best it can. After all the next pass may
 |> have enough system resources to acquire the resource.

No, it doesn't mean this.  The function terminate will only be called if
the program is already doing a stack walkback as a result of a thrown
exception.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Kevin J. Bowman" <kbowman@medar.com> writes:

|>  For some time I have been designing classes that throw
|>  exceptions from a constructor. This helps to catch
|>  problems with the allocation of resources. Recently
|>  I have been working on a class which needs to make
|>  sure that a system resource has been restored to a
|>  previous state when the object (that changed the
|>  resource on creation) is destroyed. If, for some
|>  reason, the resource could not be restored to its
|>  previous state, I throw an exception. However, I
|>  see a potential problem with this: if the destructor
|>  throws an exception, the destructor does not complete
|>  and the object is not destroyed (unless I attempt to
|>  fix the problem and try to destroy it again in the
|>  future). This could lead to a memory leak.
|>
|>  I know it's *legal* to throw an exception from a
|>  destructor but my question is: is it acceptable to
|>  throw an exception from a destructor or not?
|>  I'd like to hear comments pro and con.

The general concensus is that it is a bad idea.  C++ doesn't support
nested exceptions.  If the destructor exits because of an exception
during stack walkback due to another exception being thrown, terminate
will be called.  And if you're using exceptions, it is difficult to
prevent this case.

In general, if something can fail, it should be in an explicitly called
function, rather than the destructor, so that the object is still around
after the operation so that the operation can, eventually, be retried.

On the other hand, this specific issues you are worried about shouldn't
cause a problem if the object is correctly designed -- if a destructor
throws an exception, further execution of that destructor doesn't take
place, but if memory serves me right, all sub-objects whose destructor
has not yet been entered will be destructed.  (The wording in the last
public draft was not clear that this was the case; I believe that this
has since been made clear.  I don't think I'd count on current compilers
to implement it according to a draft that hasn't yet been made public,
however.  I'd verify, but I'm having trouble connecting to the working
group's site.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Kevin J. Bowman <kbowman@medar.com> writes:

> I have a question about the intended use of exceptions.
>
> For some time I have been designing classes that throw
> exceptions from a constructor. This helps to catch
> problems with the allocation of resources. Recently
> I have been working on a class which needs to make
> sure that a system resource has been restored to a
> previous state when the object (that changed the
> resource on creation) is destroyed.

This seems a good idea

> If, for some
> reason, the resource could not be restored to its
> previous state, I throw an exception. However, I
> see a potential problem with this: if the destructor
> throws an exception, the destructor does not complete
> and the object is not destroyed (unless I attempt to
> fix the problem and try to destroy it again in the
> future). This could lead to a memory leak.

Please be more specific. Does the object responsible for
restoring the old state contain the modified object or
not ? It would seem to me that the answer is no.

> I know it's *legal* to throw an exception from a
> destructor but my question is: is it acceptable to
> throw an exception from a destructor or not?

Yes, but with a limitation.

> I'd like to hear comments pro and con.
>
> Here is a pared down example:
>
> class A {
> public:
>     class Err {};

BTW: in general, you should derive your exceptions
classes from a common base class, like std::exception.

>     A() { /* change a resource */ }
>     ~A() { if( f() == -1) throw Err; }
>     // f() is some library function that
>     // ... returns -1 if some error occurs
> };

The problem is that during a stack walkback, if a dtor
throw, terminate () is called, which isn't in general
what you want.

To prevent that, you can test uncaught_exception ().
If it's true, then you'd better not throw; what can
you do then ?

My sugestion in this case is to have a layer of C++
exceptions, as explainned in:

http://www.pratique.fr/~bonnardv/patterns_e.html#rtti.except

Such a layer can keep more than one exception at
the same time (but it gets a little involve).

The other problem is that uncaught_exception ()
may be unavailable, and that EH may be buggy in
this area (ex. throwing in a dtor while deleting []
leaks not yet destroyed objects).

But if your compiler handle exceptions really strongly
and is up to date, then this should work.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Herb Sutter has an upcoming article

 Destructors That Throw And Why They're Evil

which I am very much looking forward to reading.  The problem
with destructors that throw is that they make it really diffucult
(probably impossible) to write exception-safe and exception-neutral
containers.  This was noted quite some time ago.  If I remember
the article (I'm not Mr. Sutter's more recent one) correctly,
the conclusion was a bit open-ended.

If you stipulate that destructors don't throw it now becomes possible
to write those containers.  And for those who argue that this stipulation
has just transferred the problem elsewhere (i.e., to the destructor) I'll
reply that this is in the spirit of exception handling: it is the client
class's responsibility.

--
John Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@nortel.ca
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> > If, for some
> > reason, the resource could not be restored to its
> > previous state, I throw an exception. However, I
> > see a potential problem with this: if the destructor
> > throws an exception, the destructor does not complete
> > and the object is not destroyed (unless I attempt to
> > fix the problem and try to destroy it again in the
> > future). This could lead to a memory leak.
>
> Please be more specific. Does the object responsible for
> restoring the old state contain the modified object or
> not ? It would seem to me that the answer is no.

My actual class encapsulates a system timer resource
(under QNX). When an object is created, the timer gets
reprogrammed with a new granularity (or resolution).
(I need to do this to get fine-grained delays). When the
object is destoryed, the timer granularity is restored
to its previous value. So the "modified object" is really
a system resource and cannot be "owned" by another object.
I have observed some problems (probably an OS bug) when
attempting to restore the clock so I thought I would
perform some sanity checks in the dtor and throw an
exception if things didn't look right.

> > Here is a pared down example:
> >
> > class A {
> > public:
> >     class Err {};
>
> BTW: in general, you should derive your exceptions
> classes from a common base class, like std::exception.

I have a base CException class but I didn't show this
in my example.


> My sugestion in this case is to have a layer of C++
> exceptions, as explainned in:
>
> http://www.pratique.fr/~bonnardv/patterns_e.html#rtti.except
>
Thanks for the (very) helpful link.

In reading through the overwhelming amount of information presented
in a previous thread, I have decided that throwing exceptions
from a dtor will probably cause more problems than I am willing
to deal with at this point (I'm sort of new to exceptions).
Thanks, everyone, for your help.

Kevin Bowman
Software Engineer

Integral Vision, A Division of Medar, Inc.
E-Mail: kbowman AT medar DOT com
Web: www.medar.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> J Kanze <kanze@gabi-soft.fr> writes:

> The general concensus is that it is a bad idea.  C++ doesn't support
> nested exceptions.

I consider "nested exceptions" to mean

try
  {
    throw 1;
  }
catch (int)
  {
    try
      {
        throw 2;
      }
    catch (int)
      {
        ...
      }
    throw;
  }

Here, the second throw generates a nested exception, because the first one
has not been completed yet (and can still be rethrown).  Similarly, an
exception thrown during stack unwinding can be caught by the destructor
before it leaks out and generates a terminate() call.  What C++ does not
support is overlapping exceptions.

Jason
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John Hickin <hickin@nortel.ca> writes:

> Herb Sutter has an upcoming article
>
>  Destructors That Throw And Why They're Evil
>
> which I am very much looking forward to reading.  The problem
> with destructors that throw is that they make it really diffucult
> (probably impossible) to write exception-safe and exception-neutral
> containers.

By definition, if a dtor throw, then it doesn't provide commit or
roll back behaviour (as destruction isn't undone), so it's clear
that it can't provide the strong garanty.

The object whose dtor throw can still provide the minimum
exception safety (well-defined behaviour, no leaks, all objects
are in a consistent state (since there are no objects)).

> This was noted quite some time ago.  If I remember
> the article (I'm not Mr. Sutter's more recent one) correctly,
> the conclusion was a bit open-ended.
>
> If you stipulate that destructors don't throw it now becomes possible
> to write those containers.

It's also possible if they throw, but it requires more work.
Handling more than one exception is annother problem.

> And for those who argue that this stipulation
> has just transferred the problem elsewhere (i.e., to the destructor) I'll
> reply that this is in the spirit of exception handling: it is the client
> class's responsibility.

There are several objects which can go into a containner.
For example, iosteams classes don't have copy ctor, nor
assignement operators. Are they evil ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Bill Dugan <wkdugan@ix.netcom.com> wrote in article
<3438aa27.2304120@nntp.ix.netcom.com>...

> There have been several discussions about this in various C++
> newsgroups in recent months. Most that I recall ended with the
> majority agreeing that throwing exceptions from destructors is a bad
> idea. A DejaNews search would probably turn up something.
> ---

Thanks - I found probably more than I ever wanted to know about
exceptions and dtors from a couple of very lengthy threads.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>
>> If you stipulate that destructors don't throw it now becomes possible
>> to write those containers.
>
>It's also possible if they throw, but it requires more work.
>Handling more than one exception is annother problem.

To quote from herb Sutter's article

        Designing Exception-Safe Generic Containers,
        C++ Report, Sept. 1997, page 23:

        We are arbitrarily going to require that T::~T() may not throw
        Why?  To make a long story short we just can't implement the
        Stack destructor with complete exception safety if T::~T() can
        throw, that's why.

This is the type of situation to which I refer.  I happen to subscribe
to this point of view.  If a container may contain more than one object
and the destructor may throw, and there is more than one possible exception
kind that may be thrown, I feel that you can't claim exception neutrality
(I'm ignoring the possibility that we are just willing to be terminated).
Remember that I did specify both exception neutrality and exception
safety as requirements.

Back when Tom Cargill's article Exception Handling: A False Sense of
Security was published, my immediate reaction was to try to take up his
challenge; the best that I could do was to add a constructor flag on the
instantiation type that controlled whether or not the destructor was
allowed to throw and I had to choose which of multiple exceptions to
propagate (it was the first one, on the basis that it was responsible
for the whole affair and was thus likely to be most of interest to the
client).  I felt then, and still do now, that I failed the challenge.

>There are several objects which can go into a containner.
>For example, iosteams classes don't have copy ctor, nor
>assignement operators. Are they evil ?

I fail to appreciate the relevance of this question in relation to my
statements.  I'll attempt to answer merely by saying that some classes
may not be suitable for membership in certain containers.  One way of
doing this is through the container's implementation.

I have the feeling that things are a lot easier in a language that
employs garbage collection.  Perhaps the issues of exception
neutrality and exception safety should be dealt with separately;
this separation of concerns is effectively a consequence of GC but
GC isn't necessarily required to achieve it.

--
John Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@nortel.ca
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Kevin J. Bowman" <kbowman@medar.com> wrote:
> > If, for some
> > reason, the resource could not be restored to its
> > previous state, I throw an exception. However, I
> > see a potential problem with this: if the destructor
> > throws an exception, the destructor does not complete
> > and the object is not destroyed (unless I attempt to
> > fix the problem and try to destroy it again in the
> > future). This could lead to a memory leak.
>
> In reading through the overwhelming amount of information presented
> in a previous thread, I have decided that throwing exceptions
> from a dtor will probably cause more problems than I am willing
> to deal with at this point (I'm sort of new to exceptions).

In light of the fact that throwing an exception within a destructor may
cause terminate() to be invoked (because the program is already in the
middle of throwing another exception, possibly from a previously invoked
destructor), the general consensus is "don't do it".

A safer approach is to call a global (or static member) function to handle
the error, in much the same way that ::new() invokes the function
established by set_new_handler() whenever it cannot allocate memory for
a new object.  This approach is simpler than dealing with exceptions.

A similar point can be made about constructors: keep them as simple as
possible (like not constructing other objects inside them) so that they
don't have to exhibit complex exception throwing behavior.

John Hickin speculated that languages which employ garbage collection are
probably better behaved about this.  He's right.  In Java, for example,
the 'finally' method for an object (which is invoked when the object is
garbage collected) cannot throw an exception.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Newsgroup: comp.std.c++

John Hickin wrote:
>
> Valentin Bonnard wrote:
> >>
> >> If you stipulate that destructors don't throw it now becomes possible
> >> to write those containers.
> >
> >It's also possible if they throw, but it requires more work.
> >Handling more than one exception is annother problem.
>
> To quote from herb Sutter's article
>
>         Designing Exception-Safe Generic Containers,
>         C++ Report, Sept. 1997, page 23:
>
>         We are arbitrarily going to require that T::~T() may not throw
>         Why?  To make a long story short we just can't implement the
>         Stack destructor with complete exception safety if T::~T() can
>         throw, that's why.
>
> This is the type of situation to which I refer.  I happen to subscribe
> to this point of view.  If a container may contain more than one object
> and the destructor may throw, and there is more than one possible exception
> kind that may be thrown, I feel that you can't claim exception neutrality

You are refering to the case where more than one failure occur. My
prefered way of dealing with this is to have a user-defined function
handle_double_fault which throw a 'summary' (for any definition of
summary) of the two exceptions.

The summary might be a pair<exception*, exception*>, the worst exception
(between read_error and no_more_filesystem, you choose
no_more_filesystem),
or anything the client wants (see also my articles in c.l.c.m in the
thread
about exceptions in the dtor for more explannations about that).

> (I'm ignoring the possibility that we are just willing to be terminated).

If you want to, just define handle_double_fault to call terminate. Of
course the intent is not to do so.

> Remember that I did specify both exception neutrality and exception
> safety as requirements.

The handle_double_fault is responsible for that.

> Back when Tom Cargill's article Exception Handling: A False Sense of
> Security was published, my immediate reaction was to try to take up his
> challenge; the best that I could do was to add a constructor flag on the
> instantiation type that controlled whether or not the destructor was
> allowed to throw and I had to choose which of multiple exceptions to
> propagate (it was the first one, on the basis that it was responsible
> for the whole affair and was thus likely to be most of interest to the
> client).  I felt then, and still do now, that I failed the challenge.

I think you did it the wrong way.

> >For example, iosteams classes don't have copy ctor, nor
> >assignement operators. Are they evil ?
>
> I fail to appreciate the relevance of this question in relation to my
> statements.  I'll attempt to answer merely by saying that some classes
> may not be suitable for membership in certain containers.

Class which throw in the dtor may not be suitable for that.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]