0

I know this is subjective, but should exceptions be caught in the lowest level or higher. I ask because I usually do

try 
{
 //..
}
catch
{
 //LOG
}

So when I implement some "low level" function, like 

std::string read_from_file(const std::string& file_name);

Im not sure what should I do:
1) let caller handle exception.
2) catch (log?) and rethrow
3) catch and change function so that bool is return type(last line in try is return true; last line in catch is return false;). I dont like this but Ive seen it done many times.
4) ???

NoSenseEtAl
  • 28,205
  • 28
  • 128
  • 277

1 Answers1

1

Catch at the level that can truly handle it or when there is no other place to throw it.

Catching and rethrowing doesn't handle anything, unless your purpose is to wrap an exception in something more illustrative (e.g. Spring persistence wraps SQLException into something more meaningful by looking at SQL error codes).

Sometimes there's no place else to go. No user should ever see a stack trace, so controllers should catch everything and redirect to a friendly error page.

You can catch and change return type, but users are losing information. "true/false" won't tell them the same info as a stack trace. Sending back "success" for a caught exception doesn't feel right to me.

If you can't handle an exception, bubble it up to a layer that can. If you can handle it, do so.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • by bool return type i mean this: last line in try is return true; last line in catch is return false; – NoSenseEtAl Jun 11 '12 at 09:35
  • Catch and rethrow with new name is usually done by library, probably to let the user of the library knows which component the error comes from. – nhahtdh Jun 11 '12 at 09:40
  • @duffymo: I just want to provide one case where catch and re-throw is used, since the question seems to be quite general to me. – nhahtdh Jun 11 '12 at 09:46
  • It seems that advice is practically universal, but the term "handle it" is not well defined. One major weakness in the exception-handling mechanisms of Java, and .net is that they strongly associate "acting on an exception" with "resolving it", when the concepts are somewhat orthogonal. If, for example, an exception occurs while trying to deserialize an object from a byte array, abandoning the partially-constructed object and dealing with the fact that it couldn't be deserialized will usually be sufficient to resolve the problem, regardless of the reason for the original exception. – supercat Jun 11 '12 at 19:16
  • Unfortunately, there's no decent way to distinguish those cases where such behavior will resolve the problem, from those which won't. It's too bad there's no standard property or other means an exception object can use to say "I haven't been resolved yet, so rethrow me." – supercat Jun 11 '12 at 19:18
  • Yes there is. You have to know your app and what an appropriate recovery strategy is. Why should there be a standard? It's up to each app to decide such a thing. – duffymo Jun 11 '12 at 19:27