10

I realize that there has been ample discussion of the relative merits of checked exceptions versus unchecked exceptions in Java, and it is not my intention to revisit the entire debate.

Rather, I would like to ask a very specific question that came to mind as I was reading Joshua Bloch's Effective Java, 2nd Edition. As I was reading, I noticed that in Item 59 ("Avoid unnecessary use of checked exceptions") Joshua gives an example in the Java API where a checked exception is used. Specifically, in Object:

protected Object clone()
            throws CloneNotSupportedException

...and then argues that it should have been an unchecked exception instead.

If the programmer using the API can do no better, an unchecked exception would be more appropriate. One example of an exception that fails this test is CloneNotSupportedException. It is thrown by Object.clone, which should be invoked only on objects that implement Cloneable (Item 11). In practice, the catch block almost always has the character of an assertion failure. The checked nature of the exception provides no benefit to the programmer, but it requires effort and complicates programs.

I then looked to see if he had an example of the converse, but I could not find one.

So I would like to ask if someone can give an example API in Java that uses an unchecked exception, but where a checked exception would have been a better choice, and explain why. A real-world example would be preferable, but I'm open to a contrived example if that would illustrate matters just as well.

Edit: To those who have voted to close this as non-constructive, I want to make it clear that I am not looking for opinion, debate, argument, or extended discussion. Nor am I taking a poll. Rather I am looking for references to examples that yield a clear analysis of how the benefits outweigh the costs. (Implicit in that is acknowledging that there are costs.) That said, I am skeptical about whether the nature of this question makes that possible. I reckon if Jon Skeet can't do it, it's unlikely that it can be done. So maybe you're right. Close if you must.

Edit: Though I'm unmoved by the response, I'm going to award this to Jon just for my accept-rate.

Community
  • 1
  • 1
pohl
  • 3,158
  • 1
  • 30
  • 48

1 Answers1

13

Yup, easily: Integer.parseInt throws NumberFormatException which is unchecked.

However, if you're ever parsing potentially-bad data, you should definitely consider catching the exception - you may very well be able to ignore that data, or perhaps report it and move on. It's not like Java has an equivalent of .NET's Int32.TryParse which lets you easily ignore bad data. Basically you need to know that you need to catch the exception, without the provocation of the compiler. Grr.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 2
    I completely agree. When you're coding and you enter "the zone" it's fairly easy to miss that certain exception that is waiting to pop up and shout "pwn3d!" either because you forgot to catch it or because you didn't know you might need to catch it... – Fritz Jun 01 '12 at 21:32
  • Thank you for your quick reply, Jon. You have chosen an example that doesn't bother me. I'm satisfied that the exception is mentioned in the JavaDoc, and I appreciate that I'm allowed to choose the scope in which to handle matters. Do you reckon that every example will come down to the same tradeoff? – pohl Jun 01 '12 at 21:42
  • @pohl: Suppose you *call* `Integer.parseInt` in one of your methods, but forget to either catch or declare it. At that point, any callers of *that* method have no clue what might happen. Still happy with that situation? – Jon Skeet Jun 01 '12 at 21:44
  • Good question. I'm sure I would feel bad for delivering a lousy product. I suppose if making this a checked exception completely absolved me from the burden of being robust to bad input I would find this line of thought compelling. I don't think it does, though. Your example is good enough to put me on the fence, at least. – pohl Jun 01 '12 at 22:10
  • 1
    ArithmeticException (http://docs.oracle.com/javase/7/docs/api/java/lang/ArithmeticException.html) would be another similar example. – emory Jun 02 '12 at 00:27
  • @JonSkeet how do you feel about the example given by @emory here? Would you want the compiler to force your hand every time you used a `/` or `%` operator? – pohl Jun 02 '12 at 15:45
  • @pohl: I personally regard "div/mod integer by integer constant" and "div/mod integer by integer variable" as distinct operations, and wouldn't mind a language which required catching exceptions when using the latter (no exceptions could be thrown in the former scenario). The latter usage is actually quite rare, so little code would need to deal with exceptions. – supercat Jun 24 '14 at 18:25