Title: Java Style & Idioms : exceptions are fun

exceptions are fun

Exceptions can be fun! Throwing and catching them in a sensible manner can help both yourself and other users of your code.

Can help to write more robust and easier to debug code.

None.

I have come across the following appalling code in some Java books:

try
  {
    // do lots of possibly dodgy stuff ...
  }
  catch (Exception e)
  {
    // junk the exceptions!
  }
an even worse example would be:
  try
  {
    // do lots of possibly dodgy stuff ...
  }
  catch (Throwable t)
  {
    // junk the throwables!
  }

these are really bad examples because they appear in books that claim to be teaching programmers how to write Java! The reason that I think this is bad practice is because the ultimate user is actually being prevented from seeing the underlying reason for failures. If they are lucky they'll get to see an error message of the form "operation failed". If they are unlucky they'll have no error message and a program that fails "silently". I am really fed up with "useless" error messages that cause me more pain than gain! (Especially when system vendors go out of their way to fully document their errors - NOT!)

The simplest way to fix the above code (assuming we have a command line based application) is to do the following relatively easy change:

  try
  {
    // do lots of possibly dodgy stuff ...
  }
  catch (Exception e)
  {
    e.printStackTrace();   // report the exceptions!
  }

Voila! The user now knows what went wrong. Such a simple little change. Sometimes the stack trace is incomplete because of JIT'ting. To get a complete stack trace [i.e. one with line numbers] you have to run the code with the JIT disabled.

The reason that you should generally not catch Throwable is because the JVM uses the Error subclass to specify abnormal conditions that should "never" arise. JavaSoft actually recommends that programmers should not trap these abnormal conditions. If you do catch them then you'll find that you don't really have many options left! Better leave them to the JVM☺

An interesting question is how to handle exceptions. The handling mechanism that one chooses would depend on the context of the code. If the code is part of a library then I think the only sensible approach is to pass all exceptions back to the user of the library. This is especially true of exceptions originating from the java.* packages [e.g. java.io.IOException]. The library author could also invent library specific exceptions applicable to the library that should be the user's responsibility to deal with.

If the code is part of a standalone application [GUI or command line] then exceptions should ultimately be visible to the user. With a command line based utility I would generally expect the full stack trace to be sufficient. One has greater freedom in the case of a GUI based application. An error-based popup can be displayed giving the useless "operation failed" message as long as the user can click on a button in the dialog box [Help/More info?] that would give the full stack trace. In either case it is usual to have supplied a context-based string to the exception constructor to make the underlying reason for the exception obvious!

Another interesting question is where to handle exceptions? The answer, of course, is that it really depends on what you are doing! In standalone applications I tend to have a catch all in my main method with a simple printStackTrace invocation. In a GUI based application I would expect the major work methods to have catch-alls with a dialog box display for the user. Individual methods may catch specific exceptions providing they handle them! One such exception is InterruptedException from Thread.sleep() I would normally expect this to be caught and either ignored as being of no real consequence or else acted upon in some manner. Note that it is acceptable to ignore it in this case because it is a specific exception under a specific circumstance.

I actually love exceptions! I think they make code easier to read. They also make it simpler to debug and maintain. When people report "problems" with my code I can usually tell what the problem is JUST by inspecting the exception! [Normally the runtime environment has not been correctly set up].

The idiom is to either catch and handle an exception sensibly or else to report it sensibly. Don't just junk them and fail silently!