Home » Uncategorized

Checked Exceptions

12 February 2004 No Comment

The use of checked exceptions is a frequently debated topic. Java uses checked exceptions and many Java developers promote them. But Java is the oddball when it comes to this topic. Practically no other OO language uses checked exceptions, and many developers think that checked exceptions are trouble.

I personally think that checked exceptions are annoying. I don’t think that its worth introducing an exception as an explicit part of an API. Many developers will simply do the following:


try
{
someOperation(...);
}
catch(Exception e)
{
}

or


try
{
someOperation(...);
}
catch(Exception e)
{
e.printStackTrace();
}

I typically do the following:


try
{
someOperation(...);
}
catch(Exception e)
{
throw new MyCustomException(e);
}

.
.

public class MyCustomException
extends RuntimeException
{
MyCustomException(Throwable t)
{
super(t);
}
}

Then at the top-level of my code, I have a single try-catch block that actually handles all of my exceptions. This makes it easy to know what to do in the face of a checked exception: you always rethrow it.

The very core of the problem with checked exceptions is that people frequently don’t do anything with them besides print them to the console.

I have come to the practice of rethrowing almost all of my Java exceptions as RuntimeExceptions or a subclass of RuntimeExceptions. I propogate all my errors up to a top-level handler that knows how to provide the right type of error screen or code to the client.

If I need to catch an exception and handle it on a lower level, I am free to do that. For example, if I am reading data from an external hardware device and it times out, I may want to handle that exception by retrying 3-4 more times, then rethrow the exception if I’m still unsuccessful. But situations like this are rare, and checked exceptions introduce an intrusive infrastructure into your code to encourage you to handle a rare occurrence. From my perspective, this is unwarranted.

By always rethrowing checked exceptions as unchecked exceptions (or runtime exceptions) in my APIs, my method signatures don’t get clogged with exceptions, and any client code that calls my code is free of having to wrap every other method call with a try/catch block. This strategy allows you to only have to think about and handle exceptions in one place for the majority of cases, but still allows you to handle exceptions at a lower level when you need to.

I enforce the contract for exceptions in my unit tests rather than in my method signatures. I actually use either a unique subclass of RuntimeException, or a subclass of RuntimeException that contains a unique error code passed into the constructor. I do this so that I can make sure that I don’t get false positives in unit tests that test for exceptions. It’s never good when you catch an exception that was thrown from a different line of code in the method that you are testing.

Here are some other references:

Checked Exceptions Are Of Dubious Value

Does Java need Checked Exceptions?

Comments are closed.