Where do you like to catch exceptions and why?

Question

Where do you like to catch exceptions and why?

I'm interested in seeing where people find it useful to put their try/catch blocks in the hope that some general patterns might emerge. I'll post my two example answers in C++ but any language is fine.

One location and reason per answer please. Thanks.

Answer 1

(Before I begin: I am a Java guy)
What I recommend:

1. Find the closest point up the call chain from the exception source where you can handle the exception properly - i.e take corrective measures, signal failure of the transaction/action etc. (Logging by itself should not be considered as handling the exceptions) All the methods between the handler and the thrower should ignore the exception. Prefer unchecked exceptions to checked ones so that the exceptions don't even figure in all those intermediate methods.
2. Layer boundaries and APIs should specify the exceptions it can throw using checked exceptions since handling those exceptions is part of the contract for the client layer/code that uses it.
3. Write an exception handler class with a handle(Exception e) method and release that to the team initially and ensure that everyone uses it to handle exceptions. Based on changing exception handling scenarios, keep adding overloaded 'handle' methods later on so that only the handler need to be modified.
4. Always remember to chain exceptions when doing catch-and-throw. This ensures that the full cause of exception gets reported.
5. Never log the same exception trace more than once. It makes it very hard to debug using log files.
6. Top level methods should have a catch clause that will catch any exception that the system may throw. This prevents spilling of our internal information to the outside world if, god forbid, things go wrong in production environment. This is more of a security requirement.

Answer 2

I try to catch ONLY those exceptions that I can deal with.

I HATE code like this:

      String s="12";
      Integer i;
        try {
          i = Integer.parseInt(s);
        } catch(ParseException pe) {
          System.out.println("hihihihihihihi!!!);
        }

What I especially hate is that what this usually does is to abort the thread anyway, because three lines later there will be an access to i that will assume that i != null.

Then you will read your stacktrace and scroll and scroll and scroll the log til you find the first signifant mistake that made everything else fall apart.

I wish Java didn't force me to catch Exceptions that I cannot deal with, anyway. But what I can do is this:

catch(Exception e) {
  throw new RuntimeException(e);
}

And I declare a lot of "throws" in my function definitions.

I am still dreaming of the day where Eclipse will automatically open a Debugger in the correct line when it will get an uncaught exception. That day, my method will open the correct line.

In other languages, like Smalltalk, I catch only the errors that I can handle. And I happily throw uncaught exceptions when the input does not meet my expectations.

The idea is that I don't want the error to be logged or documented. I want it fixed.

Answer 3

In C# and Java I prefer to not catch exceptions at all. If I can't avoid it, I rethrow a RunTime-exception immediately.

I'll always use the greediest catch block that has the largest scope needed, but always with the most specific exception-type possible. Since the outcome of the catch block is another throw in 99.99% of the cases, I try to keep the full method within the try block.