This post originated from an RSS feed registered with Java Buzz
by Weiqi Gao.
Original Post: I Like My Checked Exceptions Just Fine!
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
While I agree that Hibernate 2 probably abused checked exceptions and that Hibernate 3 is probably right in switching to unchecked exceptions, I don't believe you can blame it all on checked exceptions. The trouble with checked exception abuse has more to do with abuse than with checked exceptions.
For the record, let me just say I like my checked exceptions just fine.
I like it when my compiler compels me to think about exception handling when I call certain methods. The authors of the methods thought it important enough to alert me, the user, to make the exception checked. As a consequence I am aware of the possibility that the exception might be thrown at that spot and can choose to either handle it or propagate it. The burden of exception propagation is the price we pay for the checked exception facility in the Java compiler.
Not all exceptions are implementation details. SQLException in JDBC, for example, is part of the JDBC specification. Client code that handles or propagates SQLException are perfectly portable among different JDBC drivers. In Eric's example, HibernateException bleeds through because Hibernate chose to not use a standard Java exception class. Again, the ill lies in the fact that Hibernate uses a totally proprietary API, not that Hibernate uses checked exceptions. Plus, are we ever going to handle any Hibernate exceptions in our code, checked or unchecked? The moment we do, we just married our code to Hibernate. Having our code married to Hibernate is the price we pay for using the Hibernate library.
As for the boilerplate code that Eric alluded to, which in the most general case looks something like this:
try {
// do some lower tier thing
} catch (LowerTierCriedException e1) {
throw new ThisTierCriedException(e1);
} catch (LowerTierSmiledException e2) {
throw new ThisTierSmiledException(e2);
} catch (LowerTierYawnedException e3) {
throw new ThisTierYawnedException(e3);
}
my question is "Why?" If the answer is "I just don't want the tier above me to see any exceptions thrown by the tier below me," which is a legitimate reason for doing such things, then you have to do the wrapping regardless of the checked-ness of the exception. Otherwise the upper tier would still see the unchecked exceptions. The boilerplate code is the price we pay for cleanly separated tiers in the application architecture.
If the answer is "I don't mind lower tier exceptions bleeding through me to upper tiers. I just hate to declare these exceptions in my method signatures. I'm ready for these exceptions bubble up the stack frame and potentially kill my thread." That's a sign of lower tier checked exception abuse.
Another benefit of checked exceptions is the conceptual clarity it offered: checked exceptions are problems the client code must handle, unchecked exceptions are usually programming errors.
From a practical point of view, the use of checked exceptions has its place. We developed in Java for 10 years with checked exceptions. The JDK itself has hundred of checked exceptions. All sorts of applications were written, from small dozen-user web tools to huge popular Java based websites to high-throughput transactional servers, all while taking advantage of checked exceptions.
While googling on this subject today, I realized that my point of view might not be popular. Many smart people have spoken out against checked exceptions. Then again, I might also be in pretty good company.
Oh, BTW, I learned a new phrase while clicking on the various links today: syntactic salt—The opposite of syntactic sugar, a feature designed to make it harder to write bad code. The Wikipedia paragraph on checked exceptions classified Java's implementation of checked exception as syntactic salt.
Now that we've got the checked exceptions stuff out of the way, we can start some real discussion—"I'm going to build a bike shed, what color do you think is best?"
Previous Topic
