2001-10-18 TJSN [Issue 033] - Making Exceptions Unchecked

2001-10-18 TJSN [Issue 033] - Making Exceptions Unchecked

Author: Dr. Heinz M. Kabutz

If you are not already subscribed to this newsletter, please send an email to subscribe@javaspecialists.co.za. Be warned that if you are a beginner in Java, you will at times struggle to keep up. The archive of past newsletters is kept at http://www.javaspecialists.co.za

Welcome to the 33rd issue of "The Java(tm) Specialists' Newsletter", which some cynics say should be renamed to "The Java(tm) Hackers' Newsletter". Yes, ok, that would probably be a more appropriate name considering some of our articles, but I just find that examining some of the weird behaviour in Java helps me to understand the language better.

Thanks to all of you who responded to my last survey where I asked you to send me email if you could *not* read my newsletter. You remind me of my good friend at university who won ALL the class medals for Computer Science. I once managed to beat him in a subject (parallel computing) where I got 90+% and he got 65%. He had thought he should answer 2 out of 4 questions, whereas he should have answered 3 out of 4 questions! The problem was that he did not read the question ;-)

Meanwhile, my mailbox is quickly filling up with requests for information about the new Design Patterns course. If you have 10 or more programmers in your company that would like to attend such a course, please send me an email and I will see if I can pop around for a visit.

How do you go from being an OO beginner to an OO guru? Simple answer: Experience! What if you can't wait 10 years to get that experience? Simple answer: Design Patterns! How can you learn Design Patterns in a relaxed setting from someone who has used them in the real world? Simple answer: Ask me about my new course "Design Patterns - The Timeless Way of Coding".

Why Checked Exceptions Cause Bugs

How often have you seen code such as this?

    // ...
    try {
      // ... some code that could throw IOException or RemoteException
    } catch(Exception ex) {} // ignore

Or even worse, how about the following (from a real program whose author shall remain anonymous):

    Connection con;
    try {
      // ... make a connection
    } catch(Throwable t) {
      con = null;
    }

You can imagine what happened. At some point, the piece of code that needed to make the connection tried to load a class that was not in the classpath, with a resulting NoClassDefFoundError. The program stopped working without informing us of what had gone wrong. After a while I noticed that the class could not have been included in the classpath and was horrified to find the above code.

Why is it that so many novice Java developers write code that catches Exception and then keeps quiet about it? Is it because the compiler forces us to catch them - and most beginners then don't know how to handle them correctly? I personally like checked exceptions because they tell me what things could go wrong in my environment, although not always very clearly. For example, java.io.IOException has 47 subclasses in JDK 1.3.1, so if a method throws IOException you really don't know what actually went wrong.

Sometimes I want to catch several checked exceptions and then do something about them as a group. The problem with catching Exception is that you then also catch the unchecked exceptions, i.e. derivatives of java.lang.RuntimeException, such as NullPointerException. I like to call the unchecked exceptions programmer bug exceptions and in general you would not want to swallow those exceptions. In that case I normally do the following:

    // ...
    try {
      // ... some code that could throw IOException or RemoteException
    } catch(RuntimeException ex) {
      // programmer bug - rethrow
      throw ex;
    } catch(Exception ex) {
      // handle all the exceptions correctly
    }

Incorrect handling of exceptions is the cause of most of the bugs I have seen in novice Java programmers' code. Seeing that most Java programmers are novices due to the age of the language, we could say that, even though I like them, checked exceptions could perhaps have been a mistake. C++ doesn't have them, neither does C# and also not Python. (In case you think I'm a great visionary for thinking that they might be a mistake, I got that idea from someone else ;-)

Wrapping Checked Exceptions in Unchecked Exceptions

So how do you convert a checked exception into an unchecked exception? Here we have a code sample of how one could write an Object Adapter that would convert a checked exception into a RuntimeException. (If you don't know the difference between an object and a class adapter, and what the applicability and the consequences of each are, you should seriously consider coming to my design patterns course - see beginning of newsletter for more information.)

One of the challenges of adapting exceptions is that you want to capture the exact place where the error occurred in the program, rather than the place where the checked exception was caught. The following would therefore not be the right way to do it, as you would have an incorrect line number to blame for the fault:

    // incorrect way of adapting a checked exception
    try {
      // ... some code that could throw IOException or RemoteException
    } catch(Exception ex) {
      throw new RuntimeException(ex.toString());
    }

After some experiments, I found that the ExceptionConverter shown below works fairly well.

/**
  The ExceptionConverter changes a checked exception into an
  unchecked exception.
*/
  public class ExceptionConverter extends RuntimeException {
    /** we keep a handle to the wrapped exception */
    private final Exception ex;
    public ExceptionConverter(Exception ex) {
      this.ex = ex;
    }
    /** and allow the user of ExceptionConverter to get a handle to it. */
    public Exception getException() {
      return ex;
    }
    /** We print the message of the checked exception */
    public String getMessage() {
      return ex.getMessage();
    }
    /** and make sure we also produce a localized version */
    public String getLocalizedMessage() {
      return ex.getLocalizedMessage();
    }
    /** The toString() is changed to be prefixed with ExceptionConverter */
    public String toString() {
      return "ExceptionConverter: " + ex;
    }
    /** we have to override this as well */
    public void printStackTrace() {
      printStackTrace(System.err);
    }
    /** here we prefix, with s.print(), not s.println(), the stack
      trace with "ExceptionConverter:" */
    public void printStackTrace(java.io.PrintStream s) {
      synchronized (s) {
        s.print("ExceptionConverter: ");
        ex.printStackTrace(s);
      }
    }
    /** Again, we prefix the stack trace with "ExceptionConverter:" */
    public void printStackTrace(java.io.PrintWriter s) {
      synchronized (s) {
        s.print("ExceptionConverter: ");
        ex.printStackTrace(s);
      }
    }
    /** requests to fill in the stack trace we will have to ignore
    (I think)  We can't throw an exception here, as this method
    is called by the constructor of Throwable */
    public Throwable fillInStackTrace() {
      return this;
    }
  }

We can try this out by throwing some exceptions around:

  import java.io.IOException;
  public class ExceptionConverterTest {
    private static void f() throws IOException {
      throw new IOException("File broken");
    }
    private static void g() {
      try {
        f();
      } catch(IOException ex) {
        System.out.println("Printing out plain ol' IOException:");
        System.out.println("---");
        ex.printStackTrace();
        System.out.println("---");
        throw new ExceptionConverter(ex);
      }
    }
    public static void main(String args[]) {
      try {
        g();
      } catch(RuntimeException ex) {
        System.out.println("Printing out RuntimeException:");
        System.out.println("---");
        ex.printStackTrace();
        System.out.println("---");
        System.out.println("That's it!");
      }
    }
  }

The resulting output is:

  Printing out plain ol' IOException:
  ---
  java.io.IOException: File broken
          at ExceptionConverterTest.f(ExceptionConverterTest.java:5)
          at ExceptionConverterTest.g(ExceptionConverterTest.java:9)
          at ExceptionConverterTest.main(ExceptionConverterTest.java:20)
  ---
  Printing out RuntimeException:
  ---
  ExceptionConverter: java.io.IOException: File broken
          at ExceptionConverterTest.f(ExceptionConverterTest.java:5)
          at ExceptionConverterTest.g(ExceptionConverterTest.java:9)
          at ExceptionConverterTest.main(ExceptionConverterTest.java:20)
  ---
  That's it!

As you can see, the line numbers for the two exceptions are the same, pointing us to the exact source of our troubles, without forcing us to use checked exceptions.

Is it a good idea to adapt checked exceptions into unchecked ones? In general I would say "no". However, there are some cases where you are overriding a method which does not throw a checked exception that you need to throw and in those cases it can sometimes be useful. How often have I morphed exceptions? Not often.

I'm looking forward to your comments on this newsletter.

Cheersio

Heinz


ERRATA

In my last newsletter I made a silly mistake - I forgot to set instance back to null. The make() method of the CleverLicenseManager class should have been:

    public static CleverLicenseManager make() {
      synchronized(CleverLicenseManager.class) {
        try {
          new CleverLicenseManager();
        } catch(Exception ex) {} // ignore
        try {
          while (instance == null) {
            System.gc();
            CleverLicenseManager.class.wait(100);
          }
          return instance;
        } catch(InterruptedException ex) {
          return null;
        } finally {
          instance = null;
        }
      }
    }

(C)opyright Maximum Solutions, South Africa

Reprint Rights. Copyright subsists in all the material included in this email, but you may freely share the entire email with anyone you feel may be interested, and you may reprint excerpts both online and offline provided that you acknowledge the source as follows: This material from The Java(tm) Specialists' Newsletter by Maximum Solutions (South Africa). Please contact Maximum Solutions for more information.

Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. Maximum Solutions is independent of Sun Microsystems, Inc.