When to Use Checked and Unchecked Exceptions

[Scott Shipp]

Recently I read Grzegorz Piwowarek's article Java 8 - The Bad Parts which brought up the yuckiness of exceptions in streams. About the same time I saw a comment from Lukas Eder that the java community is unanimous that checked exceptions should be removed from the language (which is news to me). At the same time, I had a weird bug to fix at work where I found a checked exception being used for normal error handling (bad user input). To fix my story at work, I moved from a checked to a RuntimeException, since I reasoned that it is similar to an IllegalArgumentException. (Just that the illegal argument is passed in via a REST api).

But it all sent me down the path of re-reading some of the old checked vs. unchecked exceptions articles from James Gosling, Bill Venners, Brian Goetz, et. al. I actually got more confused and muddied as I revisited something that I thought I was fairly confident in.

My general rule has been something like:

- If I can imagine that the calling code can do something to recover from the error condition (besides retrying the same thing again!) and the error condition is reasonable to anticipate, then use a checked exception
- All other scenarios, use unchecked

I wonder what you all think about when to use checked vs. unchecked exceptions?

[Campbell Ritchie]

Please give us a link to that article. I think anybody who says people are unanimous even about whether grass is green is mistaken.
Checked exceptions seems to work all right when used correctly until functional programming came along; functional programming isn't happy with exceptions. And Streams are designed following the conventions of functional programming. So they don't like exceptions at all. The difference is that hardly any Stream methods declare any exceptions; those which do throw any exceptions can throw those unchecked which the compiler ignores. All is well until you use methods like BufferedReader#lines() are in a strange position. They need to use a checked exception to ensure that the reader is opened properly, but can't use a checked exception because the methods don't declare any exceptions. Read the link to see what it actually does.

Just a few thought. Doubtless other people will have other opinions and we shall have an interesting discussion here.

[Paul Clapham]

Scott, your general rule is pretty similar to Oracle's summary here: Unchecked Exceptions — The Controversy.

Personally I don't believe that checked exceptions should not be in the Java language (which apparently makes me not part of the Java community). I find it very convenient that the documentation will tell me what (checked) exceptions might be thrown by a method, and I'm perfectly happy for the compiler to "remind" me to deal with those exceptions. Sure, if all exceptions were unchecked then I could still deal with them if I wanted, but then I'd have to have some way of knowing what they were. Presumably I would have to rely on the kindness of API writers who manually documented the existence of unchecked exceptions which I might want to catch and deal with.

But I wouldn't quite put it the way you did:

If I can imagine that the calling code can do something to recover from the error condition...

It's not quite like that, but I'm not sure how to put it instead. Let me give an example instead: I wrote an application which takes messages from a queue and, based on the content of the messages, connects to FTP sites and sends files there. Now as you can imagine, sometimes the FTP sites are not reachable for various reasons. So I want to catch the exception when that happens. But obviously retrying isn't the best solution, often somebody has to call somebody else and say "Hey Orlando, your FTP site isn't responding, I'm getting this return code" before you can try again. And maybe the response is "Oh, are you guys still sending that data, we haven't been using that for months"... but anyway it's necessary to catch the exception and store the relevant information so that it's possible to send the file at a later date if necessary. Maybe you could call that "recovering" anyway? I guess my point is that when an FTP exception happens, then having the application end abnormally isn't our preferred outcome. We would prefer to note that the exception happened, perhaps do something differently, but at any rate we want the application to continue on in a normal way.

[Scott Shipp]

Campbell Ritchie wrote:Please give us a link to that article.

Sorry about that. I thought I had linked it but it looks like I somehow linked wrong. Here's the article on DZone.

[Junilu Lacar]

Scott Shipp... you wouldn't happen to be the author of this article, would you? Just wondering because I had a discussion just in the past few days with someone off-Ranch about what you wrote there. Nothing bad, I assure you. The guy I was talking to was thinking about expanding on some of your points and he and I had a discussion about working on a follow-up article together.

Anyway, as for my treatment of checked vs. unchecked exceptions, the Spring camp is probably what influences me the most. I think your general rule kind of aligns with my approach except I start with RuntimeExceptions: if it's a programming error, just let NullPointerExceptions and such happen. If it's a violation of the public contract, i.e. the JavaDocs say you shouldn't pass null, then I'd throw an IllegalArgumentException. Sometimes I'll also use IllegalStateException if the situation fits what the JavaDocs say about ISE but I'll usually review my design to see if the need to  throw an ISE isn't actually a red flag that my class design is too complicated to use.

The main thing to watch for, IMO, is copping out or worse, being lazy about checked exceptions. If you automatically wrap a checked exception with an unchecked exception and throw it back upstairs, then you have to ask if that's the right thing to do or if you're just being lazy and doing it for the sake of short-term expediency at the cost of long-term robustness of your design.

EDIT: I should point out that I can be confident in doing the above, i.e., letting RuntimeExceptions just get thrown because I also practice TDD, so these kinds of exceptions will be seen early on as I'm test-driving my development. For me, that's another advantage of TDD because it makes me include thinking about what kind of exceptions can get thrown and how I want to handle them in my design/coding process. I think many problems programmers have with checked vs. unchecked is that they don't spend time thinking about those things until later and that's usually when it's harder to change your design if you made a wrong choice early on and built out your code on top of that choice / those choices.

[Scott Shipp]

Paul Clapham wrote:...maybe you could call that "recovering" anyway? I guess my point is that when an FTP exception happens, then having the application end abnormally isn't our preferred outcome. We would prefer to note that the exception happened, perhaps do something differently, but at any rate we want the application to continue on in a normal way...

Junilu Lacar wrote:The main thing to watch for, IMO, is copping out or worse, being lazy about checked exceptions. If you automatically wrap a checked exception with an unchecked exception and throw it back upstairs, then you have to ask if that's the right thing to do or if you're just being lazy and doing it for the sake of short-term expediency at the cost of long-term robustness of your design.

Paul / Junilu  --- I think the examples you give point out something really insightful which is that exceptions are very case-by-case. The Bill Venners article gives examples from the standard library that show exceptions being used quite differently, but they all make a lot of sense in context. So maybe the reason it is hard to come up with a general rule is that a general rule isn't very helpful and common sense needs to guide you?

Junilu Lacar wrote:Scott Shipp... you wouldn't happen to be the author of this article, would you? Just wondering because I had a discussion just in the past few days with someone off-Ranch about what you wrote there. Nothing bad, I assure you. The guy I was talking to was thinking about expanding on some of your points and he and I had a discussion about working on a follow-up article together.

Ha! Guilty as charged. It was inadvertently a polarizing article, which isn't what I intended at all, but there's a fair criticism in there. I now see that I started the argument wrong and half the people who read it didn't get any nuance out of it, just "don't use getters and setters." I also am planning a follow-up article at some point, about access modifiers and why I think the big jump from package-private to public in Java allows (maybe even encourages) essentially procedural style programming. The anemic domain model article from Martin Fowler is pretty near to what I had in mind when writing that one and maybe one day I can hope to learn how to express things as well as he does.

[Junilu Lacar]

Scott Shipp wrote:... exceptions are very case-by-case. ... maybe the reason it is hard to come up with a general rule is that a general rule isn't very helpful and common sense needs to guide you?

Yup, Andy Hunt's Rule #1 applies: "Always consider context." If you're looking for *a* general rule then, no, I don't think it's possible or practical to have one statement to rule them all. If you take it in the plural, as in "general rules" or "heuristics," then yes, that's pretty much what we have, right? When we say "general" we mean "most of the time, kind of." They are rules of thumb that we like to follow based on experience. And failure. As Yoda said in Episode VIII, "The greatest teacher, failure is."

Scott Shipp wrote:... article from Martin Fowler is pretty near to what I had in mind when writing that one and maybe one day I can hope to learn how to express things as well as he does.

Don't we all have that hope?

[Junilu Lacar]

Paul Clapham wrote:Personally I don't believe that checked exceptions should not be in the Java language (which apparently makes me not part of the Java community). I find it very convenient that the documentation will tell me what (checked) exceptions might be thrown by a method, and I'm perfectly happy for the compiler to "remind" me to deal with those exceptions.

FWIW, Paul, I'm more or less with you on this.

I don't think the majority of Java developers out there even care that much about the details of the controversy per se; they just want to know which camp of smarter people "won" and what said camp recommends as the "best practice(s) for exceptions." They will then use those "best practices" as context-free rules that allow them to just do something related to exceptions so they can put a check on a box and get on with other work that's more interesting to them. That is what I referred to earlier as copping out. As cynical as it may sound, I really do believe it's true, at least based on my experience with other developers.

Developers like Scott and yourself (#samehere), however, want to have a deeper understanding of how the choices are made. We know these are significant choices and that they need to be considered in context rather than as context-free rules.

[Paul Clapham]

Yes, I have two rules which I refer to as the "Rules about Life, the Universe, and Everything".

Rule 1. "It depends."

Rule 2. "It's actually more complicated than that."