Checked Exceptions I Love You, But You Have to Go

The problem of checked exception is that they are missunderstood! For example: It doesn't make sense that the java.io package throws IOExceptions that are checked.

BUT! In business code I like them because they are part of the interface and they say: Hey there went something (business relevant) wrong!

Business exceptions are the only reason for use checked exceptions.

I totally agree and I argumented exactly the same here (together with other things I don't like of Java).

Anyway if you read the comments to my article you will discover that lots of people actually love checked exception even if I am still wondering why.

totally agree with Tony S.

not handling exceptions properly is just plain undisiplined coding

Remember C++? We could throw not an Exception object, but actually any kind of object. There were no restrictions. Going back to my code I even used to throw integers (that were my error codes). I wouldn't do that today, but it was a nice example of what "throws" meant before we got the concept of an exception.

The only positive point that I have found with exceptions is that it helps novice developers. Sometimes human nature converges with the "less possible effort" paradigm, meaning that if I don't have to write a catch block for that, i won't. And soon enough that RecordExistsException or SqlDuplicateKeyException are thrown all the way to the VM level. And in a web application that is really bad, as you can spend hours debugging if it was the view, the controller, the method, the DAO call, an inner class to JSF .... an scenario where an expert would spot the exception right on and say "it's this method because of this", a new developer would be lost in all the layers of a simple application.

With checked exceptions they have no other option than to catch them, so the code will compile. Granted most of them would do silly things like eating them and not doing anything useful (thus leaving an UI unsynchronized, the impression of an operation completed that was not because it really threw an exception)... so one would wonder if it was really an advantage. On one side, you make the developer really aware that there are some errors that they must deal with. In the other way you are just hiding important logic.

I totally disagree. Frankly, I find the "must catch - rethrow", being repeated for years, argument totally invalid.

First, because checked exceptions are a tool, and you decide when to use a checked or an unchecked exception. If there's a misuse of checked exceptions in the Java runtime, it's a problem of the runtime, not of the language feature.

Second, often the catch-rethrow MUST BE DONE because an exception changes meaning. What I'm catching as an IOException at a certain level usually means another type of failure at the business level. So, catch-rethrow in this case is a feature that a good design should consider, not a thing that I'm compelled to do because of the language.

One of the most common things that I'm seeing in customer's code is something like: Applet - calls via SpringRemoting a - Remote Service - that calls Hibernate. Of course, there's no Hibernate.jar in the Applet, as it shouldn't be there. Now, it happens that an operation on the database fails, throw a HibernateException subclass (which is a RuntimeException, so nobody caught is), gets serialized to the Applet and - ta-dah - you get a wonderful ClassNotFoundError - and the customer can't understand what's happening. Letting exceptions filter to the upper level without any check is mostly an error, especially in multi-tier applications.

Third. You're all thinking of good applications with a good test coverage, where all my cases for checked exceptions could be replaced by a very good test coverage. Now, please do a reality check. We are in the minority that write good coverages, that is a minority of people writing decent tests. That's bad, but that's life. This is not going to change in any way, neither in the short, nor in the medium period (I don't do long period forecasts by principle). In this world, having the compiler to provide some more checks with static means is a very good thing.

@Gerd: I hope I never have to use one of your API's.  You've taken a bad situation and made it worse: not only do I have to surround my calls to your API with a try/catch block, but I cannot even be sure which exceptions I might actually have to handle.

  Then you probably have to stay away from Java, since, you know, NPE is always around the corner in most Java API. Most of them are not even delcared and/or hidden by delegation or abstraction.

Then you probably have to stay away from Java, since, you know, NPE is always around the corner in most Java API. Most of them are not even delcared and/or hidden by delegation or abstraction.

 Indeed, all RuntimeExceptions are always around the corner.  In most cases, these are not declared to be thrown; so my client code can choose to either explicitly catch it, trap for it ahead of time, or let it bubble up to clients of my API. 

But declaring that a method 'throws Exception' eliminates that option for me.  If I want runtime exceptions to bubble up to a higher layer in the application, I have to handle the runtime exceptions myself.  If I want to handle a each type of checked exception individually, I am still forced to handle the top-level Exception, even though the code is unreachable.

Consider whether you really want your code to look like this:

try {
  gerdsapi.processFile(myFile); // potentially throws IOException or DataFormatException
                                // but method is only declared to throw Exception
} catch (RuntimeException re) {
  // I have to do this because Gerd refuses
  // to declare the actual checked exceptions his
  // API might throw.
  throw re;
} catch (IOException ioe) {
  throw new BusinessException("Error reading the file");
} catch (DataFormatException dfe) {
  handleDataFormatProblems(myFile);
  return false;
} catch (Exception e) {
  // This block is unreachable.  Thanks, Gerd!
}
 

I have to take issue with your unreachable catch clause example.  Yes, in this specific case you have an unreachable catch, but it's not because of any inherent behaviour of checked exceptions.

When you override or implement a method declared in a parent class, you are free to include any subset of the parent declaration's exceptions, including none, in your throws clause.  If you declare a variable of the subtype, you need only deal with the specific exceptions that the subtype throws.  If your variable is declared as the parent type, you must be able to deal with any exceptions that any of its subclasses might throw, because you've explicitly stated that you do not know which subtype you are working with.

In fact, that's how ByteArrayOutputStream works, for the most part.  None of the write() methods throws IOException, and since your variable is a ByteArrayOutputStream instance, you don't have to catch them.  The reason that your example has an unreachable catch clause is that for reasons beyond my comprehension, close() throws IOException.  There's no reason for it to do that, but it does.  That is an implementation issue for that class, not a flaw of checked exceptions.

As far as the NPE argument goes, if you're getting NPEs, your code is failing to test for null.  Your fault.  Period. Same goes for ArrayIndexOutOfBounds and a bunch of other RuntimeExceptions that will never happen in well-formed code.  That's why they're unchecked, you shouldn't ever have to catch them.

Actions, transactions, partial execution, artifacts.

The ideal way I think is to know when a job starts, gets to "try" to do its thing, and if it fails, the component that started the job, should be responsible for dealing with it. Problem is right now, that all kinds of sub components log and deal with errors inside a sub task burried deep down inside.

Exceptions should only *have* to be caught in methods marked as high-level of sorts (make up a name for it). The compiler should automatically collect all the possible exceptions and automatically mark methods as throwing everything that all the called methods can throw.

This way, in all the intermediate and low level code, you don't worry about catching exceptions. Only in that specially marked method you deal with it.

For example, in a gui application, when the user click a button, it could be the beginning of an action. A transactional object is created. The job begins. It sifts down in through a string of methods, and something could go wrong. None fo the methods worry about what they're throwing. Any method can throw whatever it wants (any exception it wants, let's not start throwings ints), and none of the low level methods worry about catching with anything. Something goes wrong, and the stack unwinds. All the stuff that has been done so far is all collected in this transactional object. The guy that started it, the code that listened for the user pressing the button, it is responsible to tellling that transactional object to undo what it did. Closing database connections, files, whatever. The user is prompted that him pressing the button caused an error and that the job could not be done. Everything is thrown out, and no damage (artifacts) are left behind all over the system. Nice and clean.

To make it work cleanly, it would be nice if there was a way to make things work in a transactional way. A bunch of stuff is attempted, and if something fails, none of the changes are seen by the outside world. Functional programming could be used for this. This way, the calculations and method calls could only ever return a result (or stuff the result in returned packages of objects). No artifacts, meaning, an exception at any part of the way, will not leave any damage around for the rest of the system.

So what I'm proposing:

• Have the compiler automatically mark a method as throwing all the exceptions that all the called methods are marked as throwing.
• (Optional) have a discipline keyword to force your lazy colleague to *have* to deal with all the possible exceptions.
• Add functional programming / transactional features to the language. What that really means is way up in the air. I wonder if Scala's functional programming features can do anything like this...

I guess, ultimately, as a quick fix to a broken language, the first point would be very beneficial I think. The "transactional" / "functional programming" aspect of it, could be hand wrapped using created objects with calculation results, only ever published to the rest of the system if it completely completes.

While I do find working with exceptions in general problematic, I disagree with most of the aruments presented here against checked exceptions.

 "The exceptions are used as away of informing us that we, as developers, have messed up.", really? This may be true in some ideal environment, but not in a real one with real world limitations. In many cases you can argue that exceptions can be folded into the return value, but that is the wrong approach IMO. For the exceptional cases now your code is more complicated and harder to read.

 "Checked exceptions force me to write catch blocks which are meaningless", your exception handling code is meaningless probably because you don't understand how you should write it and how it works. Logging and rethrowing in general is a really bad idea, do one or the other. If you rethrow, by wrapping the lower level exception into a higher level one then add conext information, this is crucial for troubleshooting or for higher code to take a decision. The arguments about noise and lost fidelity also boild down to the same thing, you have those problems because you are not using exceptions properly.

 "Unreachable code" , we should drop language features because of limitations in coverage tools or because you have this ideal of 100% coverage? C'mon. Improve your tools.

 You are saying that in most cases exceptions are bugs and recovery is not possible, well in my experience this is absolutely not true. Bug related exception in general are the unchecked ones, checked exception have nothing to do with bugs and in most cases you can recover from them.

 @migra, "Forcing a client to handle an Exception even if there is no way to handle it", how exactly are you forced to handle an exception? This is not true. Just declare your method that it throws that exception. In most cases even if you cannot handle an excetion you can (and should) add context information to it and then rethrow a higher level exception.

 @Greg, "Working with checked exceptions correctly, like working with concurrency is hard.", yes, but dropping checked exceptions based on this argument is like droping synchronization simply because it is hard to deal with. Just like for concurency, maybe the solution is some higher abstraction, but I haven't seen anything like that suggested for exceptions.

 @migra, "Forcing a client to handle an Exception even if there is no way to handle it", how exactly are you forced to handle an exception? This is not true. Just declare your method that it throws that exception. In most cases even if you cannot handle an excetion you can (and should) add context information to it and then rethrow a higher level exception.

 You force people to deal with checked exceptions, even if they cannot be handled the exception, so they have to pretend to deal with it, either by using try/catch or declaring a throws clause to that method.

There is an example of an IOException in this article that has to be handled,  nevermind the fact that it can never occure, leading to an empty catch block.

I'm sure you can deal very gracefully with SQLExceptions, right? ;)

 There is nothing you can't do with unchecked exceptions that you could do with checked exceptions , the opposite is not true.

If people do not write enough documentation for their code (especially the exceptions that could be thrown are important) they should not try to abuse checked exception to rectify the missing documentation.

On the other hand, you cannot force a developer to handle exceptions properly by using checked exceptions.If they are inept/unexpirienced/confused, checked exceptions won't help them. 

Your recommendation leads to broken encapsulation, you wouldn't wanna have all your higher level components to be aware (and thus dependent) of some Hibernate/iBatis/<insert any low level framework here> Exception, so you would have to translate the exception somewhere, there is no reason why you couldn't do exactly the same with unchecked exceptions.

This argument is imho boring, as i said before, the discussion unchecked vs. checked exceptions is over since years, checked exceptions were a mistake that has not been reproduced by any other language for good reasons.

IMO the problem is that in a certain set of situations, checked exceptions make sense - for example, if you are modelling in software, say, a hardware device or wire protocol that has a set of well-defined failure modes (think LDAP/JNDI [almost twice as many exception classes as there are non-exception classes in API - monstrous!], for example), or where, if the exceptional state is unhandled, an airplane will crash.

But software being what it is, and Java being what it is, you end up with an of API that ends up being (ab)used well beyond its intended scope, where in fact those exceptions will never happen and don't make sense.  Inheritance being what it is, there is no way to convert a parent class's exceptions into unchecked exceptions.  So we end up with APIs full of checked exceptions because they're (ab)using or inheriting from something else that throws checked exceptions.

Think about it - there are plenty of exceptions that would be *useful* as checked exceptions some small part of the time (NumberFormatException, for example;  MalformedURLException if you're writing a web browser, but practically never otherwise).  The problem might be that the division of checked/unchecked is too rigid in Java, not that one is necessarily always preferable to the other.

-Tim