Skip to main content


Posted by editor on June 22, 2007 at 7:21 AM PDT

The movement to overthrow Java's checked exceptions

So over the last few weeks, we've covered the debate in the community over the idea of ditching checked exceptions. Some developers have complained about checked exceptions over the years, but so far, it's mostly just been talk. Every now and then, you see frameworks where all the exceptions are RuntimeExceptions, and thus don't require handling, but it seems like those speaking most strongly against checked exceptions have moved on to other languages, often highly dynamic languages where checked exceptions don't make sense anyways.

But recently, Neal Gafter openly explored the idea of removing checked exceptions from Java, in response to a suggestion from a colleague who noted that much of the complexity in Gafter's closure proposal came from reconciling closures with checked exceptions. That got a strong reply from Elliotte Rusty Harold, whose Voting for Checked Exceptions calls the very idea a "hideous idea from the closures camp." Elliotte continues:

The people who object to checked exceptions mostly seem not to know the difference between checked and unchecked. Most importantly, they seem not to know when to use checked exceptions and when to use unchecked exceptions. A few libraries such as the Java USB API even get this exactly backwards. And I will admit, if you don’t know this crucial piece of information, then checked exceptions seem ugly and confusing.

Elliotte goes on to explain the proper role of each kind of exception -- checked for environmental conditions like I/O failures, unchecked for bugs that should have been caught in testing (he omits errors, which represent generally un-handleable situations like running out of memory) -- and calls Java's exception handling "the single best error handling and reporting mechanism ever built into a programming language."

But one complaint from the Devil's Advocate: if this is the right way to use these exceptions, shouldn't we be concerned if Java developers haven't figured it out 11 years after they were introduced in Java 1.0? Maybe the idea is sound in theory, but if they're being misunderstood and misapplied by so many developers, whose fault is that? Is it the developers' fault for not "getting it", for lazily doing an inappropriately low-level printStackTrace() for the sake of getting code to compile, or is the design to blame for slowing down and confusing so many otherwise capable developers?

Since this remains a major topic of discussion in the community, the latest Poll asks "Should checked exceptions be removed from Java?" Cast your vote on the front page, then check the results page for current tallies and discussion.

Our latest JavaOne Community Corner Podcast is
j1-2k7-mtT05: Java Programming Contest for University Students by Jin Yoon.
"In this session, we will explain why Sun and Ricoh have decided to organise this Java Programmming Contest for 3 successive years already and how we have managed to build an active community of more than 50 universities and 500 students. This session is a must for educational institutes, students and Java ME developers."

In Java Today,
Fabrizio Gianneschi writes, "members of the JUGs Community are invited to the JUG Leaders BOF, which will occur on June, 26 during the Jazoon Conference in Zurich, Switzerland.
It will be a special opportunity to discuss JUG-related topics, be updated about the latest initiatives and, last but not least, to see the new three Community Leaders for the first time together on the stage."

Jsasb (Java Standalone Application Service Bus), is a framework for Java stand-alone applications. It is inspired by various J2EE technologies, meaning it could be used bridge stand-alone Java code with EE. Jsasb applications consist of components (in containers) employing publish-and-subscribe or request-and-reply communications patterns. The framework also uses an ESB-like approach to separate development and assembly into two phases.

The latest issue of the JavaTools Community Newsletter has been posted, with tool-related news from around the web, announcements of new community projects and one graduation (WebLEAF) from the JavaTools incubator, and a Tool Tip on putting a scripting language in your Java webapp.

In today's Weblogs, Mark Lam discusses a trick to get
Async Thread Dumps on CVM
"Sometimes, your application appears to be hanging, and you don't quite know where it's hanging. If you're running your app on the phoneME Advanced VM (CVM), then here's a way to hack it to get a dump of the thread stacks so that you can get an idea of where your app is hung."

In Desktop development made easier with genesis, Michael Nascimento Santos writes,
"genesis 3 has just been released. This post explains what genesis is about and why you should consider it for your Swing, SWT or Thinlet application."

Finally, in
Beans Binding 0.6 Release Available, Shannon Hickey offers
"just a short note to announce that I've posted the 0.6 release of the Beans Binding project."

In today's Forums,
gmurray71 offers a lengthy set of answers in the thread
Re: Some questions regarding Jmaki.
"It's nice to see that you are digging deep into the guts of jMaki. Here are some answers to your questions. Widgets can be created on the fly and as you can see with the Injector (the API) and the DContainer (short for dynamic container which uses the injector) you can do most of what you want. If you look at the Injector code you will see that it dynamically adds widgets at runtime by default. jMaki was designed to do this from the start though there are a couple of catches."

rah003 notes classic problems with getting UI events in some Swing and SwingX components in
Re: JXHeader (JXLabel) - problem with wrapping html text.
"If I'm not mistaken, problem with JTextPane (same as with JXEditorPane) is that it consumes all the mouse events so if you add mouse listener to the JXHeader it will not receive any events if those are generated over description using JTextPane. Since description is always read only there is no really need for it to be anything with editing support or is there? If JXLabel is causing problems with resizing here we better look for a way to solve resizng problem rather the moving away to different component since sooner or later we will have to fix JXLabel anyway."

Finally, ericnishant is looking for declarative security options in
Securing JavaSE6 webservice with XWSS3.0 APIs and Ws-SecurityPolicy.
"I have been looking at this article to secure a Java SE 6 webservice with XWSS 3.0's programmatic APIs. The article outlines using XWSS 2.0 style server-side configuration files to specify the security contract. My question - Instead of the XWSS2.0-style config file, can a policy file with Ws-SecurityPolicy assertions be used ? Is this supported ; If not , is such support planned anytime soon?"

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The movement to overthrow Java's checked exceptions