Removing Checked Exceptions from Java

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.

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.

./alex
--
.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.

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?

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.

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.

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

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.

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.

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.

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.

Interesting concept; how would that be accomplished?

here...

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.

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.

(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.

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

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.

literatejava.com/exceptions/checked-exceptions-...

Checked exceptions are meaningful only in the Java compiler -- the JVM does not distinguish between checked/unchecked exceptions. Therefore Java could have it both ways, they could provide a compiler argument to control the treatment of checked exceptions e.g.:

-Xchecked-exception-handling: (neutral|throws|strict)

I'm not sure if Oracle has considered this strategy; I've only read about the either/or proposition.

Regardless, until that time you can use the Manifold compiler plugin to achieve the same goal: neutralize checked exceptions. With the exceptions plugin option enabled checked exceptions behave exactly like unchecked exceptions. No more try/catch/wrap/rethrow boilerplate nonsense, no more unintentional exception swallowing, no more lambda usage conflicts.