Skip to main content

Do you like Java's checked exceptions?

Yes, they enforce a problem-handling contract
71% (506 votes)
No, the syntax is too invasive
10% (68 votes)
No, they're usually not handled correctly anyways
17% (121 votes)
Something else (please comment)
3% (19 votes)
Total votes: 714

Comments

yes, it's very helpful

good site

dog training

Java's checked exceptions makes the programming much easy

I like 'em

I've been coding in Java for about 8 years now and I've never really given checked vs. unchecked exceptions much thought. Java has checked exceptions... I work in Java... I've never had any problems with checked exceptions... Checked exceptions are good. About 4 months ago, I started a project in C# .Net. Where did my checked exceptions go? How do I know what exceptions can be thrown from this point in my code? What I've found is that the contract provided by checked exceptions is very comforting and is a much more conservative model than relying on the unchecked exceptions to bubble up during testing. With the current Java IDEs, you know as you're typing the code exactly what is expected of you. Mmmm. Like chicken noodle soup on a cold day.

Better exception hierarchies!

While I really do like the fact, that I always know which types of exceptions I may have to deal with, I think exceptions and exception hierarchies have to be designed with great care, otherwise it becomes an unnecessary burden.
My favorite bad one is java.sql.SQLException. This is a real showstopper: It's a difference, if the database connection is gone or if the SQL has wrong syntax. You can't deal with this exception in any reasonable way (unless one considers inspection of SQL error codes as reasonable, but hey - exceptions are meant to replace error codes!)
I've seen dozens of developers (even seasoned ones!) ending up in horrible, nested try-catch-finally-blocks (yup, closing the connection requires another one).
Another one is java.io.IOException: When developing a Servlet, it would really help if you that the IO exception occured simply because the client is not alive any more...
I would not dump checked exceptions, instead I would fix the worst problems with reasonable, well-designed exception hierarchies.

Good sounding idea - poor results

Checked exceptions was a bold and smart experiment, but it failed.

  • Checked exceptions are often misused, also in the JDK. For example: MalformedURLException, CloneNotSupportedException, InterruptedException, and UnsupportedEncodingException should all have been unchecked. They have all cause me much grief, each in their own special way. If the developers of the SDK can't use checked exceptions right, what are the chances that J. Random Developer can?
  • Checked exception have caused numerous wrongfully empty catch-blocks, even in textbooks. If the authors can't get it right, what is the hope that J. Random Programmer can?
  • Checked exception makes it harder to use inheritance, decorators, and dynamic proxies.
  • Most of the time, most exceptions have to be handled at the "top level" anyway. In this case, the exception has to be passed back up through multiple layers. Handling exceptions close to the failure point is difficult to do right, and often not as valuable as you'd think. (In the cases where it was valuable, this will usually be discovered later, anyway).

In short: Java gave a try to a new idea that seemed good. It wasn't, and checked exceptions ought to be dropped.

RE: Good sounding idea - poor results

I'm surprised by the results of this poll.. but fortunately most of us disagree with you.

Checked exceptions have saved me numerous problems in my code when I've had to generate a new kind of exception. The compiler helps me find where I need to repair my code to handle that.

I used non-checked exceptions in C++ and they were a nightmare.. I'm happy Java did it right.

RE: Good sounding idea - poor results

Checked exceptions make sense in a statically typed language. However, if you want something dynamic.. it is better not to have them. (But then you shouldn't use Java, use Lisp, Smalltalk, Ruby, Python, Io, whatever)

Good sounding idea - poor results

Ye gods no. Checked exceptions should be handled as close to the problem as possible. By the time you've gone up through multiple layers of the program there is little if anything the program can do except:
(a) Fall over
(b) Throw it's hands up in the air and tell the user - gee... something went wrong but I have no idea what.
Obviously A is unacceptable - but if all exceptions were unchecled it would happen a lot more often, especially with inexperienced programmers!
Whereas when we encounter B in the wild - eg with EJB/J2EE where if an exception is thrown it gets wrapped in 40 million other exceptions before you even find out anything went wrong - it is horrible, a pain in the butt to debug, and even harder to support the code that does make it into production.

Good sounding idea - poor results

"If the authors can't get it right, what is the hope that J. Random Programmer can?" That depends on who you are. How many programmers now have a decade of Java experience and have learned the lessons taught by "Effective Java"? Ten thousand? There were obviously none developing the original Java APIs.

Good sounding idea - poor results

That depends on who you are. How many programmers now have a decade of Java experience and have learned the lessons taught by "Effective Java"? Ten thousand? There were obviously none developing the original Java APIs. What about CharsetDecoder.decode throwing CharacterCodingException (added in 1.4)? What about the disasterous new URLDecoder.decode throwing a checked exception (also added in 1.4)? These are recent additions that grossly misuse checked exceptions. Checked exceptions should be handled as close to the problem as possible. By the time you've gone up through multiple layers of the program there is little if anything the program can do except: (a) Fall over (b) Throw it's hands up in the air and tell the user - gee... something went wrong but I have no idea what. Whereas, when people try to catch exception close to their cause, they routinely: (a) Fall over (b) Throw up it's hands and log the error, proceed and then run into a NullPointerException two lines further down (c) Attempt some hare-brained retry algorithm that is never tested, and contains several bugs There are situations where you can do something meaningful with an exception, and in those cases you have to consider it carefully and make a conscious design decision about it. Trying to implement clever error handling because your compiler force you to do something might not be what you want to do...