Question

Seeing a checked expection in API is not rare, one of the most well known examples is IOException in Closeable.close(). And often dealing with this exception really annoys me. Even more annoying example was in one of our projects. It consists from several components and each component declares specific checked exception. The problem (in my opinion) is that at design time it was not exactly known what certain exceptions would be. Thus, for instance, component Configurator declared ConfiguratorExeption. When I asked why not just use unchecked exceptions, I was told that we want our app to be robust and not to blow in runtime. But it seams to be a weak argument because:

1. Most of those exceptions effectively make app unusable. Yes, it doesn’t blow up, but it cannot make anything exepting flooding log with messages.
2. Those exceptions are not specific and virtually mean that ‘something bad happened’. How client is supposed to recover?
3. In fact all recovering consists from logging exception and then swallowing it. This is performed in large try-catch statement.

I think, that this is a recurring pattern. But still checked exceptions are widely used in APIs. What is the reason for this? Are there certain types of APIs that are more appropriate for checked exceptions?

Answer 1

There have been a lot of controversy around this issue.

Take a look at this classic article about that subject http://www.mindview.net/Etc/Discussions/CheckedExceptions

I personally tend to favor the use of Runtime exceptions myself and have started to consider the use of checked exceptions a bad idea in your API.

In fact some very popular Java API’s have started to do the same, for instance, Hibernate dropped its use of checked exceptions for Runtime from version 3, the Spring Framework also favor the use of Runtime over checked exceptions.