Little Tutorials

As I said before, I am a supporter of checked exceptions in Java. I think they are a great idea that supports serious software development in the real world. I also think Java’s huge success can be attributed in part to checked exceptions. But this doesn’t mean I like everything about how the Java’s exception handling system was implemented. And there are a number of things in the exceptions class hierarchy that don’t add up in my humble opinion.

Let’s have another look at the hierarchy:

- Throwable (checked)
    - Error (unchecked)
    - Exception (checked)
        - RuntimeException (unchecked)
            - unchecked hierarchy
        - checked hierarchy

A number of weird things pop up for me:

• Why are the top level classes instantiable? Is there any benefit in being able to create instances of Throwable, Error, Exception and RuntimeException and throw them?
• Why are the unchecked exceptions extending checked exceptions?
• Why there is no CheckedException class at the top of the hierarchy to clearly separate the checked and unchecked hierarchy?

These design decisions caused some of the problems people attribute to checked exceptions.
The ability to instantiate the top level classes in the hierarchy doesn’t provide any benefit other then allowing quick hacks. I have seen APIs that throw Exception instances, thus forcing the client code to catch Exception. This is one scenario where if you don’t pay attention RuntimeException instances will be swallowed in the wrong place. In order to treat them properly you have to catch them in a specific catch block and treat or re-throw them.

try
{
    ...
}
catch (Exception e)
{
    // runtime exceptions are swallowed probably without intent
}

vs.

try
{
    ...
}
catch (RuntimeException e)
{
    throw e; // avoid swallowing
}
catch (Exception e)
{
    // only checked exceptions get caught here
}

The problem of swallowed exceptions exists also due to the small design decision of deriving RuntimeException from Exception. This causes no end of grief for people who don’t take enough time to understand the effects of what they throw and what they catch.

It is clear that the compiler and the JVM know the top level exception class hierarchy by name and treat them in special ways. At the implementation level there is no marker for checked or unchecked exceptions. So it would have been easy in my opinion to keep the hierarchy clean and separate checked and unchecked exceptions. That would have avoided many problems and pain. But now it is too late so we have to deal with what exists.

Next time I will try to dig deeper into the impact checked and unchecked exceptions have on how APIs and applications are designed.

This post is part of an ongoing series:

• 1. Exceptional Java - Thoughts on Java exceptions
• 2. Exceptional Java - Some exceptions are more equal than others
• 3. Exceptional Java - Less than perfect exceptions hierarchy
• 4. Exceptional Java - Checked exceptions are priceless… For everything else there is the RuntimeException
• 5. Exceptional Java - Design the failure case - Part 1
• 6. Exceptional Java - Design the failure case - Part 2
• 7. Exceptional Java - Exception design relativity

Filed under: Java Language, Opinions by Daniel Pietraru