Ready for InfoQ 3.0? Try the new design and let us know what you think!

Removing Checked Exceptions from Java

| by Geoffrey Wiseman Follow 0 Followers on May 30, 2007. Estimated reading time: 2 minutes |

Neal Gafter asked a question that many Java developers have asked themselves and each other: "would the language and platform be better off without checked exceptions?"

He summarized the argument against checked exceptions this way:

There has been an ongoing debate on the utility of checked exceptions. Many people are critical of Java's checked exceptions, characterizing them as a failed experiment in software engineering. In practice, checked exceptions can result in API complexity, and programs appear to be cluttered with exception handling code just to satisfy the compiler. Some people believe checked exceptions are a good language feature but are misused, even in the JDK. With the "experts" being such poor role models, how can we expect ordinary Java programmers to do better?

The discussion that follows in the comment threads seems to indicate that this is a topic that polarizes people's opinions, something about which many developers have an opinion, such as these from 'Anonymous', Christian Plesner Hansen, Henri and Cedric respectively:

You have no idea how some code in the wild looks like; people catching root exception and throwing six or seven specialized exceptions, or surrounding business logic with a variety of exceptions and then throwing Exception, or catching exceptions and then throwing error codes, or leaving catch blocks empty or catching NullPointerException
I ran my own little crusade against checked exceptions a while back. I opened an RFE (#6376696) and discussed it with some of the relevant people at Sun. There was very little interest in doing anything about it and the RFE was ultimately closed as a "won't fix" .... Checked exceptions just don't work.
I suspect I'm in the minority of liking checked exceptions ... removing checked exceptions will encourage worse code as applications will simply fall over when something goes wrong. The libraries will have stopped encouraging developers to think about the consequences of an error.
Count me firmly on the side of people who find checked exceptions very important to build API's on big code bases. Sure, they can be misused, but unchecked exceptions are being overused in a lot of places as well.

So, are checked exceptions working? Is it a good idea that just hasn't always been well-applied, or a failed experiment that should be terminated?

This also raises a more general topic of removing features from Java. If we add features to the language, but avoid removing them, the language remains on a path to increasing complexity. Is it possible to remove features as we go, reducing the complexity of the language, without harming the language in other ways? Should we be removing deprecated methods, upgrading old APIs without holding backwards-compatibility as sacrosanct?

Follow the conversation about the future of Java by staying tuned to the Java community here at InfoQ.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Checked Exceptions by David Skelly

Oh, please. What is the point of this post? This whole thing has been done to death and all we ever get from this is the same old flame war, with arguments back and forwards. OK, so it's a quiet week and you're short of things to put on the site about Java, but you could come up with something better than this. This isn't a discussion about "the future of Java". It's a pointless whinge-fest.

Re: Checked Exceptions by Alex Popescu

I assume that the same question coming from Java parent will make you wonder what is going on. For me it is quite the same when this question is coming from one of the java compiler parents. It is just making me think again about the topic -- and maybe in a newer, fresher and different light.

.w( the_mindstorm )p.
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder

PS: InfoQ policy is to always be polite with the other community members and respect their opinions.

Re: Checked Exceptions by Geoffrey Wiseman

This discussion has been occurring on and off for years, yes, but that it's been raised directly by someone like Neal Gafter, who was once a tech lead for Sun's java compiler ant tools, it feels to me like the discussion could be reaching another level.

This is a discussion that has never really reached a satisfactory conclusion, so I was interested to encourage people to participate in the discussion. Personally, I've got mixed emotions about checked exceptions, so I'm still open to hearing opinions on the subject, of which there were some interesting ones in the thread I referenced.

I'm also interested in the subject of keeping Java simple, and removing unnecessary features, a subject on which this touches.

If you're sick of hearing people discuss checked exceptions, by all means, no need to follow this dicussion; I'm not sure that's true for all of the people who may have read this news.

"the future of Java" is probably a little over the top, probably overzealous writing on my part there.

Fair enough?

Re: Checked Exceptions by Kishore Senji

Yes, I would also be interested in hearing people on this. Personally, I thought checked exceptions will give you an idea of all the abnormal conditions where a program will fail giving an opportunity to handle those conditions appropriately. If all the exceptions were unchecked wouldn't the testing be difficult as well especially when integrating with some other party libraries as it will be kind of a guessing game to know all the failure points (assuming the javadoc or any other documentation is poor for that library) and if not properly coded for all the abnormal conditions, the application would fail unpredictably at runtime. I'm sure there would be certainly a good rationale backing the all unchecked exceptions proposal/theory as it comes from the java compiler parent which I would be greatly interested in hearing.

Re: Checked Exceptions by Martin Jonsson

The following article is really enlightening regarding this subject:

Effective Java Exceptions

Contingency (checked exception)
An expected condition demanding an alternative response from a method that can be expressed in terms of the method's intended purpose. The caller of the method expects these kinds of conditions and has a strategy for coping with them.

Fault (unchecked exception)
An unplanned condition that prevents a method from achieving its intended purpose that cannot be described without reference to the method's internal implementation.

Re: Checked Exceptions by Rob Thornton

That article was also covered on InfoQ in January, with a few interesting comments.

Re: Checked Exceptions by Jonathan Allen

Being a former Java programmer and current .NET programmer, I have found that I don't miss checked exceptions. Testing is just as hard under Java as it is .NET because Java encourages people to wrap checked exceptions with unchecked ones. Often there is no way to implement an interface while exposing the correct checked exceptions.

There is also a difference in philosophy that plays into this. With .NET, the assumption is that you do not handle exceptions locally unless you really know how to handle it. This means if it isn't documented, you are meant to pass it on to your global exception handler.

Re: Checked Exceptions by Geoffrey Wiseman

With .NET, the assumption is that you do not handle exceptions locally unless you really know how to handle it. This means if it isn't documented, you are meant to pass it on to your global exception handler.

This isn't very different from how people handle exceptions in Java much of the time -- it's just more work. ;)

Checked or Not? by Jonathan Locke

Regardless of which camp you're in, I think we can all agree that both current approaches are flawed:

- Not checking exceptions is pretty much insane.

- Making static assertions about exceptions in classes at declaration time is stupid because fixes the assertion at a time when the usage environment is unknown. Such assertions are clearly impossible to make accurately and will be cumbersome in some cases and missing in others.

I have some simple ideas that would fix this problem which I will eventually post to my blog or write up as part of a book or research paper. The basic root of the problem is that you MUST take the usage context into consideration when doing exception checking. It seems kindof crazy that this isn't the way it's currently done.

Re: Checked Exceptions by Jonathan Locke

Although this distinction helps some, it is not a solution. What is a fault in one context is a contingency in another, and vice versa. The only thing that will ever solve this problem to the satisfaction of all is to redesign the exception-checking mechanism to take the usage context into consideration. I have argued this at both Sun and Microsoft, but it apparently has fallen on deaf ears.

Re: Checked or Not? by Geoffrey Wiseman

Interesting concept; how would that be accomplished?

More Discussions by Geoffrey Wiseman

Re: Checked or Not? by Jonathan Locke

A real answer would require a whitepaper (which will have to wait indefinitely, unless someone has a grant for me). The basic idea is to define sets of default throw/catch semantic checks (possibly not just /that/ an exception must be caught, but also assertions about /where/ it must be caught) perhaps based on the current static checks, but then allow rule overrides to change those semantics at various scopes (package hierarchy, package, class and method) of the usage context. There are a whole bunch of thorny problems here, of course, but I believe they all have reasonable solutions.

Re: Checked or Not? by Cristian Botiza

I think the "real" problem here is our laziness as developers. The JLS states very clear what is a checked exception. It indicates something we EXPECT could go wrong and generally know how to handle.

I agree with checked exceptions, especially in the context of frameworks. And state-of-the-art IDEs can help us by generating the appropriate try/catch clauses. The real problem comes when we have to decide and select what would make it into a checked exception, so that we add it in the throws clause. If it appears in an interface, it clearly states that all possible implementations might throw that in certain conditions. It is a matter of properly documenting the code, which I agree is a problem with many pieces of code we use today.
And I am very annoyed when I see catch(Throwable e)-like clause in the code. It makes the caller that the code is perfect and no further reasoning is required on it. Is this really true?

Depending on the context you may or may not need to catch a checked exception. Small programs we do for experimenting may easily declare throws Exception in the declaration of main(String[]). But J2EE servers deployed with production applications need to know exactly what happened and react - log the problem, fix it if possible.

To conclude, I'd say we can very well leave with checked exceptions as long as we obey the JLS exactly. I'm kind of traditionalist, I know.

Re: Checked or Not? by Colm Smyth

(thanks to Geoffrey Wiseman for linking to my post on this in which I summarise the pros and cons in the Checked Exceptions debate and recommend a solution)

This issue continues to recur with strong feelings on both sides. Developers of enterprise applications clearly recognise the value of checked exceptions to document potential errors, but developers of simpler applications with less rigorous integrity requirements find checked exceptions onerous.

Java should not only serve one type of developer, it should support different styles of development and different levels of robustness. Sun has recognised this for several years and has already made significant changes (Java 5, 6; EJB 3) to enable its platform to be more readily and easily used.

There is a way to solve this without taking away checked exceptions for the majority of *current* Java developers who want them, in the interests of making Java more accessible to future developers. I encourage you to take a look especially at the recommendation section of my existing post and to decide if you would want to give your support to a JSR to implement this. You will notice that in the preferred incarnation, it is possible to clearly identify code that is choosing to abdicate responsibility for dealing with checked exceptions and to "upgrade" it later to handle them.

Handling exceptions outside the code? by Amir Barnea

Any of you have an opinion on handling (catching) exceptions outside the code? At the JVM level? products like . . .? Is it useful at all?

Checked Exceptions versus "throw early, catch late" Best Practice by Tom Whitmore

Good points. Checked exceptions were originally intended to highlight contingencies, but were always incompatible with best-practice "throw early, catch late" exception-handling/ and FP functional programming constructs.

Instead of being being used solely for contingencies, though, they became used for all sorts of unrecoverable low-level systemic failure.

This was the fundamental misuse, the mistake of various API engineers at Sun, which saw them become such a big problem. The original concept was never intended to cover unrecoverable failures.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

17 Discuss