0

Which/what is the correct place/way to catch an exception? Say method m1 throws exception e1. And method m2 calls to m1. Should I catch exception e1 in m2. Or can I avoid using the try-catch block in the m2, if I know that m3 calls to m2 and I have in m3

try
{
  m2();
}
catch
{
....
}
Rarw
  • 7,645
  • 3
  • 28
  • 46
YAKOVM
  • 9,805
  • 31
  • 116
  • 217
  • 2
    well... this can be debated. Is rather a problem of style and preference. Typically a method should deal with exceptions that are related to its inner functionality and throw exceptions related to what the method should do. Then it depends also on the language. Check this:http://stackoverflow.com/questions/2737328/why-should-i-not-wrap-every-block-in-try-catch – Olimpiu POP Jan 08 '14 at 13:42
  • In general, see [tag:exception-handling]. – John Saunders Jan 08 '14 at 13:47

3 Answers3

3

I don't think there is a hard and fast rule on when to use a try/catch block instead of simply propagating the exception further. However, as general rule it makes sense to only use a try/catch block when the method that includes that block can effectively handle the exception that it catches. It makes no sense to catch exceptions if you can't do anything with them.

In relation to your question above, if there is no sensible way to handle the exception within M2, but there is one in M3, I would continue to throw the exception up the chain. Otherwise if you can handle it in M2, go for it.

Rarw
  • 7,645
  • 3
  • 28
  • 46
3

When in doubt use the following logic: Is the current method fully capable of dealing with the exception in such a way that the potential callers are not aware that the exception ever happened?

  • If yes, then catch and deal with the exception in the method itself.
  • If not, then does the method have any unfinished or extra work in case of an exception (logging, etc.)?
    • If yes, then catch the exception, do the work and rethrow the exception.
    • If not, then do not catch the exception at all, but rather let it bubble up the call stack

In short, only handle exceptions when you are locally fully capable of recovering.

Boris B.
  • 4,933
  • 1
  • 28
  • 59
0

an important question to ask is 'should I be catching exceptions here at all?' if you are dealing with an external resource like the disk then the answer is probably yes and otherwise its probably no - your code is better if it crashes when it has a bug in!

Following the above it's generally best to keep your try-catches as small as possible so you dont accidentally hide any bugs in your code. I think in your example that puts it in m1.

This way you also dont have to write try-catches in all client code for a method that gets used more than once. Following this logic you typically end up with a result object (or possibly more simply return null if appropriate) which can be queried to see if there is an error. Better yet you could have this result object throw its own exception if there was an error but someone is trying to read the results of the failed operation (if appropriate). In this way you can use exceptions to avoid programming errors... as long as you dont catch exceptions as a way of controlling the flow of a program.

Im sure there are plenty of other opinions on the topic though

JonnyRaa
  • 7,559
  • 6
  • 45
  • 49