right usage of std::uncaught_exception in a destructor - c++

There are some articles concluding "never throw an exception from a destructor", and "std::uncaught_exception() is not useful", for example:
http://www.gotw.ca/gotw/047.htm (written by Herb Sutter)
But it seems that I am not getting the point. So I wrote a small testing example (see below).
Since everything is fine with the testing example I would very appreciate some comments regarding what might be wrong with it ?
testing results:
./main
Foo::~Foo(): caught exception - but have pending exception - ignoring
int main(int, char**): caught exception: from int Foo::bar(int)
./main 1
Foo::~Foo(): caught exception - but *no* exception is pending - rethrowing
int main(int, char**): caught exception: from Foo::~Foo()
example:
// file main.cpp
// build with e.g. "make main"
// tested successfully on Ubuntu-Karmic with g++ v4.4.1
#include <iostream>
class Foo {
public:
int bar(int i) {
if (0 == i)
throw(std::string("from ") + __PRETTY_FUNCTION__);
else
return i+1;
}
~Foo() {
bool exc_pending=std::uncaught_exception();
try {
bar(0);
} catch (const std::string &e) {
// ensure that no new exception has been created in the meantime
if (std::uncaught_exception()) exc_pending = true;
if (exc_pending) {
std::cerr << __PRETTY_FUNCTION__
<< ": caught exception - but have pending exception - ignoring"
<< std::endl;
} else {
std::cerr << __PRETTY_FUNCTION__
<< ": caught exception - but *no* exception is pending - rethrowing"
<< std::endl;
throw(std::string("from ") + __PRETTY_FUNCTION__);
}
}
}
};
int main(int argc, char** argv) {
try {
Foo f;
// will throw an exception in Foo::bar() if no arguments given. Otherwise
// an exception from Foo::~Foo() is thrown.
f.bar(argc-1);
} catch (const std::string &e) {
std::cerr << __PRETTY_FUNCTION__ << ": caught exception: " << e << std::endl;
}
return 0;
}
ADDED: In other words: despite of the warnings in some articles it works as expected - so what might be wrong with it?

Herb Sutter is referring to a different issue. He's talking about:
try
{
}
catch (...)
{
try
{
// here, std::uncaught_exception() will return true
// but it is still safe to throw an exception because
// we have opened a new try block
}
catch (...)
{
}
}
So the problem is that if std::uncaught_exception() returns true you don't know for sure whether you can safely throw an exception or not. You end up having to avoid throwing an exception when std::uncaught_exception() returns true just to be safe.

There's nothing technically wrong with your code. It's perfectly safe in that you will never accidentally terminate because you threw an exception when it was not safe to. The issue is that it also is not useful, in that it will occasionally also not throw an exception when it is safe to. Your destructor's documentation basically has to say "this might or might not throw an exception."
If it occasionally won't throw an exception, you might as well never throw an exception. That way, you're at least consistent.

Herb Sutter is talking about the situation when an object of class T is destroyed while there is an uncaught exception in an object of class U. std::uncaught_exception() would return true in the T destructor. The destructor would be unable to find out whether it's called during stack unwinding. If it is, it must not throw, otherwise it's business as usual.
The class U would have a problem using class T in the destructor. U would find itself dealing with a useless T object that would refuse to do anything risky in its destructor (that could include writing a log file or committing a transaction to a database).
Herb Sutter suggests never throwing in a destructor, which is a good idea. However, the C++17 offers another option. It introduced std::uncaught_exceptions(), which can be used to find out whether the destructor can throw. Following example shows the problem if complied in C++14 mode. If compiled in C++17 mode, it would work correctly.
#include <exception>
#include <iostream>
#include <string>
class T
{
public:
~T() noexcept(false)
{
#if __cplusplus >= 201703L
// C++17 - correct check
if (std::uncaught_exceptions() == uncaught_exceptions_)
#else
// Older C++ - incorrect check
if (!std::uncaught_exception())
#endif
{
throw (std::string{__PRETTY_FUNCTION__} + " doing real work");
}
else
{
std::cerr << __PRETTY_FUNCTION__ << " cowardly quitting\n";
}
}
private:
#if __cplusplus >= 201703L
const int uncaught_exceptions_ {std::uncaught_exceptions()};
#endif
};
class U
{
public:
~U()
{
try
{
T t;
}
catch (const std::string &e)
{
std::cerr << __PRETTY_FUNCTION__ << " caught: " << e << '\n';
}
}
};
int main()
{
try
{
U u;
throw (std::string{__PRETTY_FUNCTION__} + " threw an exception");
}
catch (const std::string &e)
{
std::cerr << __PRETTY_FUNCTION__ << " caught: " << e << '\n';
}
return 0;
}

Related

c++ destructor throw exception by single object

I'm trying to understand why throwing an exception from a destructor results in a program crash.
As I found many examples of two object which throw multiple exception and compiler can't handle multiple exception but in my case I only have a single exception thrown from the destructor. Why is my program still crashing?
class MyClass {
private:
string name;
public:
MyClass (string s) :name(s) {
cout << "constructor " << name << endl;
}
~MyClass() {
cout << "Destroying " << name << endl;
throw "invalid";
}
};
int main( )
{
try {
MyClass mainObj("M");
}
catch (const char *e) {
cout << "exception: " << e << endl;
cout << "Mission impossible!\n";
}
catch (...) {
cout << "exception: " << endl;
}
return 0;
}
Explanation from the MingW g++ compiler:
[P:\temp]
> g++ foo.cpp
foo.cpp: In destructor 'MyClass::~MyClass()':
foo.cpp:14:15: warning: throw will always call terminate() [-Wterminate]
throw "invalid";
^~~~~~~~~
foo.cpp:14:15: note: in C++11 destructors default to noexcept
To really let it throw you can do this:
~MyClass() noexcept(false){
Since C++11 destructors are implicitly declared as noexcept documentation
non-throwing functions are all others (those with noexcept specifier whose expression evaluates to true as well as destructors, defaulted special member functions, and deallocation functions)
emphasis is mine.

Program ends with "abort() has been called" error on VS2017

Below code exits by giving error
"abort() has been called".
Is it due to destructor throwing exception? I know throwing exception from destructor results in undefined behavior but there are counter arguments also. and moreover the same program works correct in VS 2012.
#include "stdafx.h"
#include<iostream>
using namespace std;
class Txn
{
public:
Txn()
{
cout<< "in Constructor" << endl;
};
~Txn()
{
try
{
cout << "in destructor" << endl;
throw 10;
}
catch(int i)
{
cout << "in destructor exception" << endl;
throw;
}
}
};
int main()
{
try
{
Txn t;
}
catch (int i)
{
cout << "Exception" << i << endl;
}
return 0;
}
VS2017 release notes does not mention anything around exception handling changes.
So i have below questions:
Is it incorrect to throw exception in destructor from VS2017 onwards? will it always exit the program by calling abort()?
Are there any flags with which we can make it work?
Please suggest.
The issue here is all destructors by default are noexcept(true). Throwing an exception without changing the will call std::terminate immediately. If we use
class Txn
{
public:
Txn()
{
cout<< "in Constructor" << endl;
};
~Txn() noexcept(false)
{
try
{
cout << "in destructor" << endl;
throw 10;
}
catch(int i)
{
cout << "in destructor exception" << endl;
throw;
}
}
};
int main()
{
try
{
Txn t;
}
catch (int i)
{
cout << "Exception" << i << endl;
}
return 0;
}
The program runs as expected.
The reason this worked in VS2012 but not VS2017 is before C++11 a destructor could throw without you needing to specify it. With C++11 noexcept specifiers and the change that all destructors are noexcept by default causes it to break in VS2017.
Destructors are by default expected to not throw exceptions (noexcept). You can tell the compiler that this destructor is not using the default by adding a noexcept(false).
When trying that on this example, we now get a different diagnostic from the compiler - that the destructor will never, ever reach the end. It's not good for a destructor to never fully destroy the object...
To "fix" this I had to make the rethrow conditional with an if.
class Txn
{
public:
Txn()
{
cout<< "in Constructor" << endl;
};
~Txn() noexcept(false)
{
try
{
cout << "in destructor" << endl;
throw 10;
}
catch(int i)
{
cout << "in destructor exception" << endl;
if (i == 10) throw;
}
}
};
Undefined behaviour can be anything, including a call to abort(); Just avoid everything that may induce it.
Throwing from the destructor is not forbidden, but doing that inside a try/catch might result in double exception thrown.

How do I use boost's set_exception_handler?

I want to set a global exception handler in C++. With a hook, any exceptions (of a specified type) thrown, would be caught by the handler. With this, I could do a little pretty printing before the exception kills the program, or maybe I could write everything to a log file.
boost seems to have an exception handler hook. This seemed extremely promising, but the code provided didn't work as I thought it should. Am I missing something?
struct my_handler
{
typedef void result_type;
void operator() (std::runtime_error const& e) const
{
std::cout << "std::runtime_error: " << e.what() << std::endl;
}
void operator() (std::logic_error const& e) const
{
std::cout << "std::logic_error: " << e.what() << std::endl;
throw;
}
};
void init_exception_handler()
{
// Setup a global exception handler that will call my_handler::operator()
// for the specified exception types
logging::core::get()->set_exception_handler(logging::make_exception_handler<
std::runtime_error,
std::logic_error
>(my_handler()));
}
// The above is all code from the boost doc example. Untouched.
int main(int argc, char* argv[]) {
init_exception_handler();
// I can throw now right...?
throw std::runtime_error("This should be suppressed!");
return 0;
}
In this code, the runtime_error I throw is not suppressed even though I thought I had setup the exception handler.

Can't catch a C++ exception

I'd like to catch an exception while trying to use copy constructor of some class, which would throw.
#include <iostream>
class dont_copy_me {
public:
dont_copy_me() {}
dont_copy_me(const dont_copy_me& rhs) {throw;}
dont_copy_me(dont_copy_me&& rhs) {throw;}
~dont_copy_me() {}
};
int main() {
try {
dont_copy_me obj;
dont_copy_me obj_1(obj);
} catch(...) {
std::cout << "exception caught" << std::endl;
}
return 0;
}
But I keep getting
terminate called without an active exception
Aborted (core dumped)
What is wrong? How do I catch the exception thrown by copy constructor? (because that's what I need)
Actually throw an exception like this:
#include <iostream>
#include <stdexcept>
class dont_copy_me {
public:
dont_copy_me() {}
dont_copy_me(const dont_copy_me& rhs) {throw std::runtime_error("Fail!");}
dont_copy_me(dont_copy_me&& rhs) {throw std::runtime_error("Fail!");}
~dont_copy_me() {}
};
int main() {
try {
dont_copy_me obj;
dont_copy_me obj_1(obj);
} catch(...) {
std::cout << "exception caught" << std::endl;
}
return 0;
}
This does what you need. Here you can find a list of standard exceptions (under "Exception categories").
The empty throw expression only works when you are already handling an active exception:
Rethrows the currently handled exception. Abandons the execution of the current catch block and passes control to the next matching exception handler (but not to another catch clause after the same try block: its compound-statement is considered to have been 'exited'), reusing the existing exception object: no new objects are made. This form is only allowed when an exception is presently being handled (it calls std::terminate if used otherwise). The catch clause associated with a function-try-block must exit via rethrowing if used on a constructor.
From here, emphasis mine.
Your catch (...) block is fine, the problem is your program does not throw an exception.
There are two forms of throw expression:
throw <some-exception> create and throw an exception
throw re-throw the current exception
In your code, you are calling the second form from your copy constructors. Use the first form instead.
The second form is used when you want to some partial handling of an exception. Here's a contrived example program that uses both forms:
#include <cstdexcept>
#include <cstdlib>
#include <iostream>
int main()
{
int ret = EXIT_FAILURE ;
try
{
try
{
throw std::logic_error("Fail!"); // form 1
ret = EXIT_SUCCESS;
}
catch (...)
{
std::clog << "re-throwing" << std::endl;
throw; // form 2
}
}
catch (...)
{
std::cerr << "unhandled exception" << std::endl;
}
return ret;
}
See: http://en.cppreference.com/w/cpp/language/throw

Determining exception type after the exception is caught?

Is there a way to determine the exception type even know you caught the exception with a catch all?
Example:
try
{
SomeBigFunction();
}
catch(...)
{
//Determine exception type here
}
Short Answer: No.
Long Answer:
If you derive all your exceptions from a common base type (say std::exception) and catch this explicitly then you can use this to get type information from your exception.
But you should be using the feature of catch to catch as specific type of exception and then working from there.
The only real use for catch(...) is:
Catch: and throw away exception (stop exception escaping destructor).
Catch: Log an unknwon exception happend and re-throw.
Edited:
You can extract type information via dynamic_cast<>() or via typid()
Though as stated above this is not somthing I recomend. Use the case statements.
#include <stdexcept>
#include <iostream>
class X: public std::runtime_error // I use runtime_error a lot
{ // its derived from std::exception
public: // And has an implementation of what()
X(std::string const& msg):
runtime_error(msg)
{}
};
int main()
{
try
{
throw X("Test");
}
catch(std::exception const& e)
{
std::cout << "Message: " << e.what() << "\n";
/*
* Note this is platform/compiler specific
* Your milage may very
*/
std::cout << "Type: " << typeid(e).name() << "\n";
}
}
You can actully determine type inside a catch(...), but it is not very useful:
#include <iostream>
#include <exception>
class E1 : public std::exception {};
class E2 : public std::exception {};
int main() {
try {
throw E2();
}
catch( ... ) {
try {
throw;
}
catch( const E1 & e ) {
std::cout << "E1\n";
}
catch( const E2 & e ) {
std::cout << "E2\n";
}
}
}
There is no standard, portable way to do this. Here's a non-portable way to do it on GCC and clang
#include <iostream>
#include <cxxabi.h>
const char* currentExceptionTypeName()
{
int status;
return abi::__cxa_demangle(abi::__cxa_current_exception_type()->name(), 0, 0, &status);
}
int main()
{
try {
throw std::string();
} catch (...) {
std::cout<<"Type of caught exception is "<<currentExceptionTypeName()<<std::endl;
}
return 0;
}
Output:
Type of caught exception is std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
provided that c++11 available,
bool throwing_func()
{
// something is wrong...
throw char('5');
// ...
return true;
}
void exception_handler(std::exception_ptr _Eptr)
{
try
{
if (_Eptr) {std::rethrow_exception(_Eptr);}
}
catch(int _Xi)
{
std::cout << "int\n";
}
catch(char _Xc)
{
std::cout << "char\n";
}
catch(const std::exception& _Xe)
{
std::cout << "std::exception " << _Xe.what() << "\n";
}
catch (...)
{// develop more catch cases above to avoid what follows
std::cout << "unhandled exception\n";
// grande problema
}
}
int main()
{
try
{
throwing_func();
}
catch(...)
{
//Determine exception type here
exception_handler(std::current_exception());
}
return 0;
}
If you need to handle exceptions differently based on what they are, you should be catching specific exceptions. If there are groups of exceptions that all need to be handled identically, deriving them from a common base class and catching the base class would be the way to go. Leverage the power and paradigms of the language, don't fight against them!
No.
Doing so would at the very least require you to be able to access the current exception. I do not believe there is a standard way of doing this.
Once you had the exception instance, you would have to use a type inspection algorithm. C++ doesn't have inherent support for this. At best you would have to have a big if/elseif statement with dynamic_cast's to check the type.
This question was asked some time ago and I'm offering this answer as a companion to the accepted answer from 9 years ago. I'd have to concur with that respondent that that answer, "... is not very useful." Further, it opens the door to an exception which was once handled being unhandled. To illustrate, let me build upon the respondent's answer
#include <iostream>
#include <exception>
class E1 : public std::exception {};
class E2 : public std::exception {};
class E3 : public std::exception {};
int main() {
try {
throw E3();
}
catch( ... ) {
try {
// OOOPS!!! E3 is now unhandled!!!!!!
throw;
}
catch( const E1 & e ) {
std::cout << "E1\n";
}
catch( const E2 & e ) {
std::cout << "E2\n";
}
}
}
An alternative to this approach would be the following:
#include <iostream>
#include <exception>
class E1 : public std::exception {};
class E2 : public std::exception {};
class E3 : public std::exception {};
int main() {
try {
throw E3();
}
catch( const E1 & e ) {
std::cout << "E1\n";
}
catch( const E2 & e ) {
std::cout << "E2\n";
}
catch( ... ) {
std::cout << "Catch-all...";
}
}
This second approach seems to be tantamount to the first and has the advantage of specifically handling E1 and E2 and then catching everything else. This is offered only as an alternative.
Please note that, according to C++ draft of 2011-02-28, paragraph 15.3, bullet item 5, "If present, a ... handler shall be the last handler for its try block."
I've tried various ways; this works for me:
Begin by subclassing runtime_error :
/*----------------------------------------------------------------------*/
/* subclass runtime_error for safe exceptions in try/throw/catch */
#include <stdexcept>
/* a little preprocessor magic here -- makes a subclass of runtime_error*/
#define NEWERROR( NE ) class NE : public runtime_error { \
public: NE ( string const& error ) : runtime_error(error) {} }
NEWERROR( FileError );
NEWERROR( NetworkError );
NEWERROR( StringError );
NEWERROR( CofeeError );
/*----------------------------------------------------------------------*/
Then you may create some instances of your exceptions.
/*----------------------------------------------------------------------*/
/* some example pre-defined exceptions */
FileError ReadOnly ( "ReadOnly" );
FileError FileNotFound ( "FileNotFound" );
NetworkError TimeOutExceeded ( "TimeOutExceeded" );
NetworkError HostNotFound ( "HostNotFound" );
CoffeeError OutOfCoffee ( "OutOfCoffee" );
/*----------------------------------------------------------------------*/
Explicitly notify the compiler that your function may throw an exception
or the program will probably terminate at the point thrown, and data could be lost or corrupted
if resources are in use at the time.
"Make sure you can and do catch anything that you can throw."
(I use the generic runtime_error because throwing and catching it covers all of
my exceptions plus the systems' ones as well.)
/*----------------------------------------------------------------------*/
/* example function that may throw an exception */
#include <fstream>
ifstream& getFileStream (string fname) throw (runtime_error)
{
if ( fname == "" )
throw StringError( "<getFileStream> fname:empty string" );
// processing stops here if thrown
try
{
ifstream Inputfstream;
ifstream& ifsref = Inputfstream;
// ifstream has its own <legacy> exception
// mechanisms and procedures
ifsref.exceptions ( ifstream::failbit | ifstream::badbit );
ifsref.open (fname , ifstream::in); // could fail ==> ifstream::failure exception
}
catch (ifstream::failure e)
{
throw FileError( fname + string(e.what() ) );
}
return ifsref;
}
/*----------------------------------------------------------------------*/
then in your try/catch
/*----------------------------------------------------------------------*/
catch (FileNotFound fnf) //catch a specific error
{
if (DEBUG) cerr << "[File Not Found Error: " << fnf.what() << "]" << endl;
... (handle it) ...
}
catch (FileError fe) //catch a specific type
{
if (DEBUG) cerr << "[File Error: " << fe.what() << "]" << endl;
... (handle it) ...
}
catch (runtime_error re ) // catch a generic type
{
if (DEBUG) cerr << "[Runtime error: " << re.what() << "]" << endl;
// determine type by string comparison
if ( re.what() == string("ResourceNotavailable") ) ...
if ( re.what() == string("NetWorkError") ) ...
...
}
catch ( ... ) // catch everything else
{ ... exit, rethrow, or ignore ... }
/*----------------------------------------------------------------------*/
The runtime-error class has good support in the c++ standard libraries,
and compilers know about it internally, and how to optimize memory and dispatch,
so you can use them over different code bases safely and confidently. The code is portable and compatible with many different compilers and architectures.
It may be preferable and somewhat faster to catch each error separately in a catch clause, from more specific to more generic,if you feel a series of string matches is a terrible waste of cpu and memory (the compiler optimizes these though ).
<stdexcept> gives you several kinds of exceptions in 2 groups:
Logic errors:
logic_error
domain_error
invalid_argument
length_error
out_of_range
Runtime errors:
runtime_error
range_error
overflow_error
underflow_error
usage syntax is slightly different for some of them.
Conventional Wisdom in C++ says that your exceptions should be relatively "flat",
meaning that large hierarchies of specific categories of exceptions should be eschewed in
favor of short generic but informative ones for general programming tasks. Domain specific tasks like network system logic, higher maths, etc. may benefit from specificity, but that can be achieved handily by making intelligent error strings with generic runtime/logic exceptions.
Lastly, My Point is: You can achieve all of this by
throwing and catching only runtime_error.
You don't have to create a whole trick-bag of highly specific exceptions
(like java does) for each class, each handling one specific error.
If you're using Visual C++ (managed), you can use the GetType() method to get the type of exception and handle it from there.
E.g.
try
{
// Run the application
Application::Run(mainForm);
}
catch (Exception^ e)
{
String^ exception_type = e->GetType()->ToString();
throw;
}
The string will contain something like "System.ArgumentOutOfRangeException".