BT

InfoQ Homepage News Removing Checked Exceptions from Java

Removing Checked Exceptions from Java

Bookmarks

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
Style

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.

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

Community comments

  • Checked Exceptions

    by David Skelly /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Checked Exceptions

    by Geoffrey Wiseman /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: Checked Exceptions

    by Jonathan Allen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting concept; how would that be accomplished?

  • More Discussions

    by Geoffrey Wiseman /

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Re: Checked or Not?

    by Jonathan Locke /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

  • Checked Exceptions versus "throw early, catch late" Best Practice

    by Tom Whitmore /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Why not both? You decide with Manifold.

    by Scott McKinney /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

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

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

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.