Why is SQLException a checked exception

Can anyone think of a rational reason why SQLException is a checked exception?

Yes, there could be a syntax error in the query Yes, the connection might have died Yes, there might be a permission problem Etc, etc blah blah blah

But practically 100% of the time (once you're running in production), there isn't any problem.

If there is a problem, the calling code can't do anything to recover, so for that reason it should be unchecked.

Being checked create masses of perfunctory try catch blocks throughout the code, as anyone who has been involved with a project that uses JDBC will attest. The code clutter is significant.

Because of the esoteric nature of SQL, the myriad of reasons you may get an SQLException and their complexity means you basically can not recover, unless the exception is caused by temporary network problem, but even then in a synchronous call, you're sunk anyway because you can't wait indefinitely for the network problem to be resolved, so you're going to have to fail the transaction.

Typically, calling SQL looks like this:

try {
    // make some SQL call(s)
} catch {SQLException e) { 
    // log the exception
    return; // and give up

Such code adds no value. There nothing reasonable you can do to recover. You might as well let a runtime exception bubble up - ie SQLException should be a runtime (unchecked) exception.


One reason would be that a method should throw exception which are consistent with the abstraction level of what the method does.

So a method which loads information from a database should not raise a SQLException, but rather a ResourceNotFoundException or a ResourceUnavailableException.

Making the SQLException checked is a way to force the developper to catch the Exception and wrap it in this new level of abstraction.

This argument is taken from Effective Java Second Edition by Joshua Bloch (Item 61: Throw exceptions appropriate to the abstraction).

practically 100% of the time there isn't any problem - This is limited to your own observation which says nothing about other systems. There are various computer systems around the world with various bottlenecks. Your success rate is almost 100%. Others have to deal with much lower percentage.

Common misconception is to consider introducing/removing a Checked Exception by frequency of its occurrence. Checked exceptions serve as communication channels. As you know, every method has its public interface. This way, method tells us which arguments it accepts and what is result of the code in its body.

When it becomes impossible for a method currently being in progress to keep its promise (e.g. returned value) it needs a way to tell the other method that something went wrong and it can't do what was expected. But how to do it ? Sending the message as the value returned doesn't work, there is almost no chance for the calling method to distinguish between proper value and an error message. Not to say some methods have void as a return value. So what do you do when you're unable to keep your promise defined by your method's interface ? Well, you throw an exception (send a message).

If you expect ResultSet and there is no connection to your database established, what should you do ? Return empty ResultSet ? Hell no, this tells us that the database is empty. Return null ? Well, this only delegates the problem and makes finding the cause unclear.

You could use that empty resultset and make it a part of another query to another database, making it inconsistent.

Without SQLException, even one mistake could lead to data inconsistency.

Catching exceptions grant us the ability to recover from exceptional conditions, true, but they also allow us to do other things.

You cannot recover from a SQLException in that there isn't much you can do to fix the problem at run time, but there are some useful things you can do:

  • Log the exception for debugging information
  • Rollback a transaction

You could always log the exception at a higher level (or lower, depending on perspective), but you lose some semantic value, both at debugging time and when reviewing the code.

If you do something like:

try { ... }
catch(SQLException e) 
    throw e;

and come back to this code later, you'll instantly realize that the code in the try can fail without having to mentally parse the code to determine if it can fail.

Another thing you could do is ensure any database resources have been released, though I'm not sure if this can happen off hand.

There are a couple of approaches to the checked vs unchecked dilemma. Checking if the calling code can recover from the exception or not is one approach, this one however, I agree, does not explain why SQLExcption is a checked exception.

Another one, provided by Martin Fowler in his great book "Refactoring" suggests to verify wether it is the calling or the called method responsibility to make a check that might result in an exception.

If the caller method should perform a check prior calling the called method (e.g. making sure the arguments are not not null) then if this check has not been done it is clearly a programming error and then the called method should thrown an unchecked exception.

Now if it is the called method responsibility to make the check, because only this method can know how to perform such check then the exception thrown from the called method should be checked.

In case of SQLException I think only this class can know:

  • there is a syntax error in the query as this depends on the database
  • the connection has died
  • there is a permission problem

Need Your Help

Firebase Security rule to restrict up to some characters of a string

firebase firebase-security

How to restrict user to save string that is above some limit?

Full GC only release little memory in PSOldGen

java memory garbage-collection jvm

We have performed a server migration from Solaris SunOS 5.10 to Redhat Linux VM recently. JVM was upgraded from 1.5.0_22 (32-bit) to 1.6.0_06 (64-bit)

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.