Tracking change and innovation in the enterprise software development community
Defy all
Challenges.
Microsoft®
Visual Studio
2008
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Geoffrey Wiseman on May 30, 2007 07:30 AM
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.
Evolutionary Design through Agile Development Podcast
Gaining Control of Changing Requirements Webcast
Six Free Project Management Certification Training Courses
Continuous Application Performance eKit - Articles, Discussion Panel, Whitepapers, Demos
Offshore software development: Making it a success with Agile Practices
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.
This isn't very different from how people handle exceptions in Java much of the time -- it's just more work. ;)
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?
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?
Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.
Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.
Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.
Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).
Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.
Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.
In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.
In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.
16 comments
Reply