Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Removing Checked Exceptions from Java

Removing Checked Exceptions from Java

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