c++ try catch practices

问题:

Is this considered good programming practice in C++:

try {
// some code

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

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

回答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.

回答2:

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

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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.

回答7:

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.

回答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.

回答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

回答10:

Never speak in absolutes. I would say you should almost never swallow an exception. However, here is a place in my code where I have done it without really bothering me:

class _ACLASS dstream 
    : public ofstream
{
//...
    long GetSize (void);
//...
Protected:
    string CheckRotation(void);
//...
};

string dstream::CheckRotation(void)
{   
//...
        // rotate if they aren't the same (it's a new day)
        // or our current file size exceeds the limit.
        if (currDay != newDay || GetSize() > fileSizeLimit * ONE_MEGABYTE)
        {
//...             
            Purge(); // while all files are closed, look for purge opportunity
            clear();
            open(Destination);
//...
}

// Return current file size
long dstream::GetSize (void)
{
    long retval =0;
    try {  // PBI 1227 was caused by this not being trapped.
        retval = (long)tellp ();
    } catch (...) { 
        retval =0; 
    } // Swallow the exception if any

    return retval;
}

Here I'm just trying to determine if my log file has exceeded 1 M byte (or hwever many M bytes allowed by fileSizeLimit), and if so, rotate the log. If I get an exception here, I will just be reporting a 0 byte size to the caller and the caller will not choose to rotate the log at this time. On the next call, it likely will get a correct answer and pass that on.

I suppose if tellp() throws an exception every single call, my log would not rotate until midnight. But I doubt this can happen (and I've never seen it in the field)