throwing exceptions out of a destructor

Question

Most people say never throw an exception out of a destructor - doing so results in undefined behavior  Stroustrup makes the point that  the vector destructor explicitly invokes the destructor for every element  This implies that if an element destructor throws  the vector destruction fails    There is really no good way to protect against exceptions thrown from destructors  so the library makes no guarantees if an element destructor throws   from Appendix E3 2    This article seems to say otherwise - that throwing destructors are more or less okay   So my question is this - if throwing from a destructor results in undefined behavior  how do you handle errors that occur during a destructor   If an error occurs during a cleanup operation  do you just ignore it  If it is an error that can potentially be handled up the stack but not right in the destructor  doesn t it make sense to throw an exception out of the destructor   Obviously these kinds of errors are rare  but possible

User · Answer

As an addition to the main answers  which are good  comprehensive and accurate  I would like to comment about the article you reference - the one that says  throwing exceptions in destructors is not so bad    The article takes the line  what are the alternatives to throwing exceptions   and lists some problems with each of the alternatives  Having done so it concludes that because we can t find a problem-free alternative we should keep throwing exceptions    The trouble is is that none of the problems it lists with the alternatives are anywhere near as bad as the exception behaviour  which  let s remember  is  undefined behaviour of your program   Some of the author s objections include  aesthetically ugly  and  encourage bad style   Now which would you rather have  A program with bad style  or one which exhibited undefined behaviour

User · Answer

So my question is this - if throwing from a destructor results in   undefined behavior  how do you handle errors that occur during a   destructor    The main problem is this  you can t fail to fail  What does it mean to fail to fail  after all  If committing a transaction to a database fails  and it fails to fail  fails to rollback   what happens to the integrity of our data   Since destructors are invoked for both normal and exceptional  fail  paths  they themselves cannot fail or else we re  failing to fail    This is a conceptually difficult problem but often the solution is to just find a way to make sure that failing cannot fail  For example  a database might write changes prior to committing to an external data structure or file  If the transaction fails  then the file data structure can be tossed away  All it has to then ensure is that committing the changes from that external structure file an atomic transaction that can t fail      The pragmatic solution is perhaps just make sure that the chances of   failing on failure are astronomically improbable  since making things   impossible to fail to fail can be almost impossible in some cases    The most proper solution to me is to write your non-cleanup logic in a way such that the cleanup logic can t fail  For example  if you re tempted to create a new data structure in order to clean up an existing data structure  then perhaps you might seek to create that auxiliary structure in advance so that we no longer have to create it inside a destructor   This is all much easier said than done  admittedly  but it s the only really proper way I see to go about it  Sometimes I think there should be an ability to write separate destructor logic for normal execution paths away from exceptional ones  since sometimes destructors feel a little bit like they have double the responsibilities by trying to handle both  an example is scope guards which require explicit dismissal  they wouldn t require this if they could differentiate exceptional destruction paths from non-exceptional ones    Still the ultimate problem is that we can t fail to fail  and it s a hard conceptual design problem to solve perfectly in all cases  It does get easier if you don t get too wrapped up in complex control structures with tons of teeny objects interacting with each other  and instead model your designs in a slightly bulkier fashion  example  particle system with a destructor to destroy the entire particle system  not a separate non-trivial destructor per particle   When you model your designs at this kind of coarser level  you have less non-trivial destructors to deal with  and can also often afford whatever memory processing overhead is required to make sure your destructors cannot fail   And that s one of the easiest solutions naturally is to use destructors less often  In the particle example above  perhaps upon destroying removing a particle  some things should be done that could fail for whatever reason  In that case  instead of invoking such logic through the particle s dtor which could be executed in an exceptional path  you could instead have it all done by the particle system when it removes a particle  Removing a particle might always be done during a non-exceptional path  If the system is destroyed  maybe it can just purge all particles and not bother with that individual particle removal logic which can fail  while the logic that can fail is only executed during the particle system s normal execution when it s removing one or more particles   There are often solutions like that which crop up if you avoid dealing with lots of teeny objects with non-trivial destructors  Where you can get tangled up in a mess where it seems almost impossible to be exception-safety is when you do get tangled up in lots of teeny objects that all have non-trivial dtors   It would help a lot if nothrow noexcept actually translated into a compiler error if anything which specifies it  including virtual functions which should inherit the noexcept specification of its base class  attempted to invoke anything that could throw  This way we d be able to catch all this stuff at compile-time if we actually write a destructor inadvertently which could throw

User · Answer

Martin Ba  above  is on the right track- you architect differently for RELEASE and COMMIT logic   For Release   You should eat any errors  You re freeing memory  closing connections  etc  Nobody else in the system should ever SEE those things again  and you re handing back resources to the OS  If it looks like you need real error handling here  its likely a consequence of design flaws in your object model   For Commit   This is where you want the same kind of RAII wrapper objects that things like std  lock guard are providing for mutexes  With those you don t put the commit logic in the dtor AT ALL  You have a dedicated API for it  then wrapper objects that will RAII commit it in THEIR dtors and handle the errors there  Remember  you can CATCH exceptions in a destructor just fine  its issuing them that s deadly  This also lets you implement policy and different error handling just by building a different wrapper  e g  std  unique lock vs  std  lock guard   and ensures you won t forget to call the commit logic- which is the only half-way decent justification for putting it in a dtor in the 1st place

User · Answer

Throwing an exception out of a destructor is dangerous  If another exception is already propagating the application will terminate   include  lt iostream gt   class Bad       public             Added the noexcept false  so the code keeps its original meaning             Post C  11 destructors are by default  noexcept true   and            this will  by default  call terminate if an exception is            escapes the destructor                        But this example is designed to show that terminate is called            if two exceptions are propagating at the same time           Bad   noexcept false                        throw 1               class Bad2       public           Bad2                         throw 1                 int main int argc  char  argv          try               Bad   bad            catch                    std  cout  lt  lt   quot Print This n quot              try               if  argc  gt  3                        Bad   bad     This destructor will throw an exception that escapes  see above              throw 2       But having two exceptions propagating at the                           same time causes terminate to be called                    else                       Bad2  bad     The exception in this destructor will                           cause terminate to be called                      catch                    std  cout  lt  lt   quot Never print this n quot             This basically boils down to  Anything dangerous  i e  that could throw an exception  should be done via public methods  not necessarily directly   The user of your class can then potentially handle these situations by using the public methods and catching any potential exceptions  The destructor will then finish off the object by calling these methods  if the user did not do so explicitly   but any exceptions throw are caught and dropped  after attempting to fix the problem   So in effect you pass the responsibility onto the user  If the user is in a position to correct exceptions they will manually call the appropriate functions and processes any errors  If the user of the object is not worried  as the object will be destroyed  then the destructor is left to take care of business  An example  std  fstream The close   method can potentially throw an exception  The destructor calls close   if the file has been opened but makes sure that any exceptions do not propagate out of the destructor  So if the user of a file object wants to do special handling for problems associated to closing the file they will manually call close   and handle any exceptions  If on the other hand they do not care then the destructor will be left to handle the situation  Scott Myers has an excellent article about the subject in his book  quot Effective C   quot  Edit  Apparently also in  quot More Effective C   quot  Item 11   Prevent exceptions from leaving destructors

User · Answer

As an addition to the main answers  which are good  comprehensive and accurate  I would like to comment about the article you reference - the one that says  throwing exceptions in destructors is not so bad    The article takes the line  what are the alternatives to throwing exceptions   and lists some problems with each of the alternatives  Having done so it concludes that because we can t find a problem-free alternative we should keep throwing exceptions    The trouble is is that none of the problems it lists with the alternatives are anywhere near as bad as the exception behaviour  which  let s remember  is  undefined behaviour of your program   Some of the author s objections include  aesthetically ugly  and  encourage bad style   Now which would you rather have  A program with bad style  or one which exhibited undefined behaviour

User · Answer

We have to differentiate here instead of blindly following general advice for specific cases   Note that the following ignores the issue of containers of objects and what to do in the face of multiple d tors of objects inside containers   And it can be ignored partially  as some objects are just no good fit to put into a container    The whole problem becomes easier to think about when we split classes in two types  A class dtor can have two different responsibilities     R  release semantics  aka free that memory   C  commit semantics  aka flush file to disk    If we view the question this way  then I think that it can be argued that  R  semantics should never cause an exception from a dtor as there is a  nothing we can do about it and b  many free-resource operations do not even provide for error checking  e g  void free void  p     Objects with  C  semantics  like a file object that needs to successfully flush it s data or a   scope guarded   database connection that does a commit in the dtor are of a different kind  We can do something about the error  on the application level  and we really should not continue as if nothing happened   If we follow the RAII route and allow for objects that have  C  semantics in their d tors I think we then also have to allow for the odd case where such d tors can throw  It follows that you should not put such objects into containers and it also follows that the program can still terminate   if a commit-dtor throws while another exception is active     With regard to error handling  Commit   Rollback semantics  and exceptions  there is a good talk by one Andrei Alexandrescu  Error Handling in C     Declarative Control Flow  held at NDC 2014   In the details  he explains how the Folly library implements an UncaughtExceptionCounter for their ScopeGuard tooling    I should note that others also had similar ideas    While the talk doesn t focus on throwing from a d tor  it shows a tool that can be used today to get rid of the problems with when to throw from a d tor    In the future  there may be a std feature for this  see N3614  and a discussion about it   Upd  17  The C  17 std feature for this is std  uncaught exceptions afaikt  I ll quickly quote the cppref article      Notes      An example where int-returning uncaught exceptions is used is         first   creates a guard object and records the number of uncaught exceptions   in its constructor  The output is performed by the guard object s   destructor unless foo   throws  in which case the number of uncaught   exceptions in the destructor is greater than what the constructor   observed

User · Answer

From the ISO draft for C    ISO IEC JTC 1 SC 22 N 4411   So destructors should generally catch exceptions and not let them propagate out of the destructor      3 The process of calling destructors for automatic objects constructed on the path from a try block to a throw-     expression is called    stack unwinding       Note  If a destructor called during stack unwinding exits with an     exception  std  terminate is called  15 5 1   So destructors should generally catch exceptions and not let     them propagate out of the destructor      end note

User · Answer

Its dangerous  but it also doesn t make sense from a readability code understandability standpoint   What you have to ask is in this situation  int foo        Object o        As foo exits  o s destructor is called     What should catch the exception  Should the caller of foo  Or should foo handle it  Why should the caller of foo care about some object internal to foo  There might be a way the language defines this to make sense  but its going to be unreadable and difficult to understand   More importantly  where does the memory for Object go  Where does the memory the object owned go  Is it still allocated  ostensibly because the destructor failed   Consider also the object was in stack space  so its obviously gone regardless   Then consider this case  class Object       Object2 obj2     Object3  obj3     virtual  Object                  What should happen when this fails  How would I actually destroy this         delete obj3             obj 2 fails to destruct when it goes out of scope  now what               should the exception propogate              When the delete of obj3 fails  how do I actually delete in a way that is guaranteed to not fail  Its my memory dammit   Now consider in the first code snippet Object goes away automatically because its on the stack while Object3 is on the heap  Since the pointer to Object3 is gone  you re kind of SOL  You have a memory leak   Now one safe way to do things is the following  class Socket       virtual  Socket               try                     Close                  catch                             Why did close fail  make sure it  really  does close here                      Also see this FAQ

User · Answer

Everyone else has explained why throwing destructors are terrible    what can you do about it   If you re doing an operation that may fail  create a separate public method that performs cleanup and can throw arbitrary exceptions   In most cases  users will ignore that   If users want to monitor the success failure of the cleanup  they can simply call the explicit cleanup routine   For example   class TempFile   public      TempFile       throws if the file couldn t be created      TempFile   throw       does nothing if close   was already called  never throws     void close       throws if the file couldn t be deleted  e g  file is open by another process         the rest of the class omitted

User · Answer

Q  So my question is this - if   throwing from a destructor results in   undefined behavior  how do you handle   errors that occur during a destructor    A  There are several options    Let the exceptions flow out of your destructor  regardless of what s going on elsewhere  And in doing so be aware  or even fearful  that std  terminate may follow  Never let exception flow out of your destructor  May be write to a log  some big red bad text if you can   my fave   If std  uncaught exception returns false  let you exceptions flow out  If it returns true  then fall back to the logging approach    But is it good to throw in d tors   I agree with most of the above that throwing is best avoided in destructor  where it can be  But sometimes you re best off accepting it can happen  and handle it well  I d choose 3 above    There are a few odd cases where its actually a great idea to throw from a destructor  Like the  must check  error code  This is a value type which is returned from a function  If the caller reads checks the contained error code  the returned value destructs silently  But  if the returned error code has not been read by the time the return values goes out of scope  it will throw some exception  from its destructor

User · Answer

Set an alarm event  Typically alarm events are better form of notifying failure while cleaning up objects

User · Answer

I currently follow the policy  that so many are saying  that classes shouldn t actively throw exceptions from their destructors but should instead provide a public  close  method to perform the operation that could fail        but I do believe destructors for container-type classes  like a vector  should not mask exceptions thrown from classes they contain   In this case  I actually use a  free close  method that calls itself recursively   Yes  I said recursively   There s a method to this madness   Exception propagation relies on there being a stack   If a single exception occurs  then both the remaining destructors will still run and the pending exception will propagate once the routine returns  which is great   If multiple exceptions occur  then  depending on the compiler  either that first exception will propagate or the program will terminate  which is okay   If so many exceptions occur that the recursion overflows the stack then something is seriously wrong  and someone s going to find out about it  which is also okay   Personally  I err on the side of errors blowing up rather than being hidden  secret  and insidious   The point is that the container remains neutral  and it s up to the contained classes to decide whether they behave or misbehave with regard to throwing exceptions from their destructors

User · Answer

The real question to ask yourself about throwing from a destructor is  What can the caller do with this    Is there actually anything useful you can do with the exception  that would offset the dangers created by throwing from a destructor   If I destroy a Foo object  and the Foo destructor tosses out an exception  what I can reasonably do with it   I can log it  or I can ignore it   That s all   I can t  fix  it  because the Foo object is already gone   Best case  I log the exception and continue as if nothing happened  or terminate the program    Is that really worth potentially causing undefined behavior by throwing from a destructor

User · Answer

Everyone else has explained why throwing destructors are terrible    what can you do about it   If you re doing an operation that may fail  create a separate public method that performs cleanup and can throw arbitrary exceptions   In most cases  users will ignore that   If users want to monitor the success failure of the cleanup  they can simply call the explicit cleanup routine   For example   class TempFile   public      TempFile       throws if the file couldn t be created      TempFile   throw       does nothing if close   was already called  never throws     void close       throws if the file couldn t be deleted  e g  file is open by another process         the rest of the class omitted

User · Answer

Unlike constructors  where throwing exceptions can be a useful way to indicate that object creation succeeded  exceptions should not be thrown in destructors   The problem occurs when an exception is thrown from a destructor during the stack unwinding process  If that happens  the compiler is put in a situation where it doesn   t know whether to continue the stack unwinding process or handle the new exception  The end result is that your program will be terminated immediately   Consequently  the best course of action is just to abstain from using exceptions in destructors altogether  Write a message to a log file instead

User · Answer

Throwing out of a destructor can result in a crash  because this destructor might be called as part of  Stack unwinding   Stack unwinding is a procedure which takes place when an exception is thrown  In this procedure  all the objects that were pushed into the stack since the  try  and until the exception was thrown  will be terminated -  their destructors will be called  And during this procedure  another exception throw is not allowed  because it s not possible to handle two exceptions at a time  thus  this will provoke a call to abort    the program will crash and the control will return to the OS

User · Answer

Throwing out of a destructor can result in a crash  because this destructor might be called as part of  Stack unwinding   Stack unwinding is a procedure which takes place when an exception is thrown  In this procedure  all the objects that were pushed into the stack since the  try  and until the exception was thrown  will be terminated -  their destructors will be called  And during this procedure  another exception throw is not allowed  because it s not possible to handle two exceptions at a time  thus  this will provoke a call to abort    the program will crash and the control will return to the OS

User · Answer

I am in the group that considers that the  scoped guard  pattern throwing in the destructor is useful in many situations - particularly for unit tests  However  be aware that in C  11  throwing in a destructor results in a call to std  terminate since destructors are implicitly annotated with noexcept   Andrzej Krzemienski has a great post on the topic of destructors that throw     https   akrzemi1 wordpress com 2011 09 21 destructors-that-throw    He points out that C  11 has a mechanism to override the default noexcept for destructors      In C  11  a destructor is implicitly specified as noexcept  Even if you add no specification and define your destructor like this     class MyType           public   MyType     throw Exception                                   The compiler will still invisibly add specification noexcept to your destructor  And this means that the moment your destructor throws an exception  std  terminate will be called  even if there was no double-exception situation  If you are really determined to allow your destructors to throw  you will have to specify this explicitly  you have three options          Explicitly specify your destructor as noexcept false     Inherit your class from another one that already specifies its destructor as noexcept false     Put a non-static data member in your class that already specifies its destructor as noexcept false        Finally  if you do decide to throw in the destructor  you should always be aware of the risk of a double-exception  throwing while the stack is being unwind because of an exception   This would cause a call to std  terminate and it is rarely what you want  To avoid this behaviour  you can simply check if there is already an exception before throwing a new one using std  uncaught exception

User · Answer

Your destructor might be executing inside a chain of other destructors  Throwing an exception that is not caught by your immediate caller can leave multiple objects in an inconsistent state  thus causing even more problems then ignoring the error in the cleanup operation

[c++] throwing exceptions out of a destructor

Examples related to c++

Examples related to exception

Examples related to destructor

Examples related to raii