Is this considered good programming practice in C++:
try {
// some code
}
catch(someException) {
// do something
}
catch (...)
{
// left empty <-- Good Practice???
}
Is this considered good programming practice in C++:
try {
// some code
}
catch(someException) {
// do something
}
catch (...)
{
// left empty <-- Good Practice???
}
No! That is a terrible practice!
Just about the only time you should
catch (...)
and not rethrow the exception would be inmain()
to catch any otherwise unhandled exceptions and to display or log an error before exiting.If you
catch (...)
, you have absolutely no idea what exception was thrown, and thus you can't know whether it is safe to continue running.Eating exceptions is a bad idea.
At the very least, implement some kind of logging for your exceptions. You might want to consider rethrowing the exception with an error message that better describes the problem.
The only time I can think of where this might be necessary--though that still doesn't mean that it is good--is in a destructor. Destructors cannot throw or you're going to have much worse problems than whatever that exception might have been (short of a bad_alloc maybe). If there's nothing you can do about it when something does throw then your catch will be empty. You can't rethrow since you're in a destructor...it's really all you can do in that situation.
Still though, an assert in there or something would be warranted.
Of course, others have mentioned threads. I simply don't do MT so I don't know the issues there.
good practice is just:
Because you know what exception(s) you want to catch.
catch( ... ) should only be in your main() and in the entry point of threads ( no exception should leave threads), after of course a catch( const std::exception & e ).
This is one of those "it depends" questions. If you're dealing with a poorly documented, third-party library which went ahead and defined their own exception that don't inherit from std::exception you may not have any other choice. Then again, I'd only leave that in in the debug portion of my code.
Well it depends on your application and the problem you are trying to solve. But in general, it isn't a good idea to swallow unknown exceptions. At the very least, I would log something.
Edit: as Noah Roberts pointed out, about the only the only time this might be a reasonable idea would be in a destructor. It is important to suppress exceptions in destructors, otherwise you could have multiple exceptions active. This could happen, for example, if an exception is thrown, and as a result of the stack unwinding some destructor is called. If that destructor throws an exception, you'll have 2 exceptions active. C++ will then call std::terminate(), which by default will end your program. You can install a handler for this condition, but there probably isn't much you can do other than log what is happening.
Still, even in a destructor, you should probably log something inside the
catch (...)
. However, depending on which destructor it is, you may not have your logging facility available. But in most cases you could still usestd::cerr
.