Reputation: 75
Does it always make sense to catch every exception "just to make sure"? For example:
try
{
Socket_Listen();
if(Return_Value == SOCKET_ERROR)
{
throw SOCKET_LISTEN_ERROR;
}
__LOG__ << "Listening..." << endl;
}
catch(EError_ID)
{
__LOG__;
Get_Last_Error_As_String( __FUNCTION__ );
}
catch(...)
{
__LOG__ << "WARNING: An unknown error occurred." << endl;
}
I'm throwing an error I have defined myself (SOCKET_LISTEN_ERROR
), which is part of a larger enum that contains multiple error IDs. Is it possible that there is some other exception thrown here, besides the one I have thrown? For the sake of completeness, here is Socket_Listen()
:
void CTCPServer::Socket_Listen()
{
Return_Value = listen( Socket,
2 );
}
Upvotes: 2
Views: 111
Reputation: 163277
On the contrary, it rarely makes sense to catch every exception. When you exit a catch
block (without rethrowing), you're telling the surrounding code that the exception has been resolved and the program can continue running normally.
When you catch all exceptions without any knowledge of what they are, you can't possibly make the claim that everything is normal. It's better to ignore unexpected exceptions than to swallow them up. Let the caller worry about them (possibly by letting them go to the caller's caller, and so on).
You ask whether there are any other exceptions that could be thrown from that code. I don't know, and neither do you, so it certainly makes no sense to catch them. If testing reveals other kinds of exceptions, and if that location is the right place to handle them, then add code to handle them there. Until you know what to expect, though, remove the catch-all exception handler.
Upvotes: 4