c++ try catch practices

Question

Is this considered good programming practice in C++:

try {
// some code

}
catch(someException) {
// do something
}
catch (...) 
{

// left empty   <-- Good Practice???
} 

Answer 1

No! That is a terrible practice!

Just about the only time you should catch (...) and not rethrow the exception would be in main() 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.

Answer 2

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 use std::cerr.

Answer 3

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.

Answer 4

No. This is not good programming practice in C++ or in any other language.

Silent failures are bad and will bite you sooner or later.

If you are going to catch (...) the very least you should do is log that you are doing it. You may also need to delete some objects if you are not using RAII.

Answer 5

good practice is just:

try {
// some code

}
catch( const someException & e) {
// do something
}

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 ).

Answer 6

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.

Answer 7

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.

Answer 8

As a standard practise, this is a really bad idea. If you start swallowing exceptions when you don't know what to do with them, then you're a. preventing them from being dealt with in more suitable places down the call stack, and b. giving an opportunity for your program to continue in some erroneous state.

However, that said, the potential exists that you as a programmer have made the correct and logical determination that it is an appropriate time to swallow an exception. This might require follow up steps, such as performing cleanup and informing the user that an operation that they initiated failed.

Bottom line, if you can't determine the consequences of catching - don't catch.

Answer 9

Actually it really depends on what your whole program intends to do nevertheless most of the time it is not a very nice idea to swallow exceptions and continue executing as if nothing happened you need to be informed what problems actually the code had, where it crashed etc...

Başak Bilgi