In my recent post I brought up the idea of a backwards incompatible version of Java. I indicated that checked exceptions would be an obvious candidate for removal.
Java exceptions are divided into checked and unchecked. This distinction is not terribly neat in the API, because
Exception. The purpose behind the distinction between the two isn't overly clear from the Javadoc:
RuntimeExceptionis the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine. A method is not required to declare in its
throwsclause any subclasses of
RuntimeExceptionthat might be thrown during the execution of the method but not caught. The class
Exceptionand its subclasses are a form of
Throwablethat indicates conditions that a reasonable application might want to catch.
Maybe this lack of clear purpose didn't help developers use exceptions in the way intended (because the intended way wasn't specified).
In my last post, I summarised my views as follows:
If you are still using or advocating checked exceptions then I'm afraid you skill set is 5 to 10 years out of date.
I base this opinion on observation of the industry, and the behaviour of its most active participants.
Key industry projects do not use checked exceptions. Spring has a specific policy of wrapping any checked exception to make it unchecked. Hibernate changed from checked to unchecked - in the words of a key committer I spoke to at JavaOne "we threw our hands up and said sorry" about using checked exceptions. Another key player in Java EE confirmed that that specification is also moving away from checked exceptions.
But since there are some who have commented that they thought these weren't sufficient data points, I've gathered more information. I walked around the entire exhibition floor at JavaOne and asked each vendor what their Java API used. (Apologies in advance to any vendor where the information is inaccurate!)
These 10 vendors indicated that they expose only runtime exceptions:
Spring Source, Terracotta, JReport, Neo4J, Electric Cloud, Serva, Exo, n-software, Ricoh, Sahi, Splunk.
These 8 vendors indicated that they expose some checked exceptions, typically including the JDK exceptions like
JRebel, Artifactory, Caucho (limited by J2EE spec), JetBrains, Parasoft, JBoss (partially limited by J2EE spec), JRapid
These 5 vendors indicated that they expose a number of their checked exceptions, including ones they have written, like
Windward reports, Sonatype, Perforce (have own NPE for example), Blackberry, Intersystems Cache (all exceptions extend Throwable directly)
A number of other companies weren't able to provide the info, or didn't have an exposed public API.
So, there is no there is no single viewpoint by the vendors. Many now only use runtime exceptions, with others only really exposing JDK checked exceptions. However some have a wide selection of checked exceptions.
Do these data points change my analysis?
In addition to finding out what a company did, I also asked a number of people the "what if" question of removing them from JDK 9 (#bijava). Most were in favour of removing them, with those having C# experience distinctly in favour. As always, there were some who still favoured checked.
The checked exception issue will continue to be emotive. For me its a classic case of not considering the community effect as being important enough.
My take is that far too often you will see a checked exception caught and ignored, or simply print stack trace and continue. Developers are human, and they are lazy. No amount of telling developers the right way to do something is ever going to change that. Developers will always use them inappropriately.
For me, a language feature that is proven to be used incorrectly most of the time is a language feature not worth having, however logical the basic idea may seem.
My view is that broken features in the Java language should be removed. And checked exceptions are broken because in 15 years we've found it impossible to get developers to use them properly (even the JDK library has many poor examples).
Like any religious debate, I don't expect to change minds overnight. But I ask those justifying them to look a little closer at how in 15 years, we're still using them poorly. What does that say?
Feedback welcome as always! Please use #bijava to talk about backwards incompatible Java on twitter.