1

I recently experienced an issue using a couple of third party libraries. My code called library A which called library B. When Library B experienced an error, it would throw an exception; which is the preferred behavior as it doesn't know how the error should be handled. Library A would cleanup its internal resources using RAII in its' virtual destructor.

Since these resources are private to the class in A, I'm using I can't cleanup the resources ahead of time.

Now in a certain situation during the cleanup of classes I'm using in my code, the destructor in A would be called; and that in turn called B and B would throw an exception.

I wanted to catch this exception in my code since I didn't want to have to change the third party library's code. Unfortunately I found that the exception handling code wouldn't propagate the exception back to my code but would cause an abort method to be called.

I ended up changing A's third party code to catch and ignore all possible exceptions.

Since by default gcc 4.8.1 doesn't propagate exceptions through a destructor which of major compilers and versions of these compilers will or will not propagate an exception though a destructor?

dynamic_duck
  • 1
  • 2
Andrew Stern
  • 688
  • 9
  • 18
  • I have difficulty following your explanation. A code example would help. Anyway, does this occur, by any chance? "**15.2/1** As control passes from the point where an exception is thrown to a handler, destructors are invoked by a process, specified in this section, called *stack unwinding*. If a destructor directly invoked by stack unwinding exits with an exception, `std::terminate` is called (15.5.1)." – Igor Tandetnik Apr 08 '15 at 12:51
  • MyCode cleans up classes defined in A. A calls B to cleanup its' internal members. B throws exception. M -> A (Destructor) -> B (Exception). This isn't done as a part of stack unwinding. The resource owned by B is a socket connection and was already in bad shape which is why I'm clearing out my usage of the socket so that I can recreate the socket connection. This is part of a much bigger system which I don't want to crash especially while I'm trying to fix the problem operationally. – Andrew Stern Apr 08 '15 at 13:33

1 Answers1

0

I do believe that it is defined somewhere in the standard that exceptions that are thrown from destructors can cause std::terminate to be called, at least in C++11. This is because destructors are marked implicitly to be noexcept by the compiler.

  • Kind of: http://stackoverflow.com/questions/15721544/destructors-and-noexcept / http://stackoverflow.com/questions/9180164/implicit-generated-members-and-noexcept and https://akrzemi1.wordpress.com/2013/08/20/noexcept-destructors/ – Martin Ba Apr 08 '15 at 13:25
  • I liked the article at : https://akrzemi1.wordpress.com/2013/08/20/noexcept-destructors . Thanks. Still a workup of the compilers and when the behavior changed in each compiler would be helpful as this code is cross platform and runs on many different machines with multiple different versions of the same compiler. – Andrew Stern Apr 09 '15 at 13:34