Take the 2-minute tour ×

I am going through a Spring book to learn Spring. Having gone through sections about the JDBCTemplate i was surprised to find that Spring handles most of the SQLException exceptions differently.

For example, all checked exceptions are converted to unchecked exceptions. What exactly is the benefit of this?

In my experience, the majority of SQL exceptions should be handled. For example, we have an application that talks to an Oracle PL/SQL procedure. The call to the PL/SQL procedure can return an ORA-01403: no data found exception. This kind of exception is one that you usually recover from by displaying an error message to the user. e.g. A search result did not return anything.

How would this kind of a checked exception be handled in Spring if all exceptions are unchecked i.e. Spring wont force you to handle them?

I know that you can catch RuntimeExceptions but i quite liked the idea that you are forced to handle checked exceptions. What benefit does converting some of the checked exceptions to unchecked exceptions provide?

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

Some people don't like checked exceptions, as they force you to do some exception management. I guess the Spring guys are of this kind.

Personally I prefer to do things as they were intended to be made:

try {
    // execute some SQL
} catch (SQLException ex) {
    if (ex is an expected condition) {
        // deal with it: for example with a "no data found" condition
        // this might mean returning null, or throwing some kind of business exception, such as
        // NoEmployeeFoundException, or whatever
    } else {
        // this is a programming / environment error
        // throw as unchecked exception
        throw new RuntimeException(ex);

Of course the downside of this approach is that is more work. The upside is that you have explicitly stated in code which are the "expected" circumstances and which ones should not happen ever.

share|improve this answer
add comment

Yes, the exceptions should be handled, but in Spring design, on higher level then the each DAO method. In fact the design where in every method there is SQLException handling is unclean copy-paste design, and when you change something, you must apply the change in every place.

There are various demands, and various places where you handle unchecked exceptions. One of these are aspects, where you can for example convert Spring's exceptions to your exceptions (uncatched exceptions need not be declared in method signature, so this convertion is very elegant). In REST method you can add generic handler that will return the error responce to the caller, and you write exception handling in only one place. In JSF/JSP based technologies you can add own error page whenever error occures.

share|improve this answer
You don't need to handle it in the DAO, you could just declare your DAO interface as throws SQLException (or whatever exception you want your DAOs to raise). –  gpeche Jan 15 '12 at 20:05
Yes, but still you have to handle it somewhere. And even if you handle it in aspect, still throws declaration stays and you must handle exception you never get... –  Łukasz 웃 L ツ Jan 15 '12 at 20:56
Well you always have to handle exceptions, except in development. Otherwise your program terminates in a uncontrolled way. –  gpeche Jan 15 '12 at 21:55
Yes, but you can do it in aspect, or in task dispatcher, or in queue, or anywhere else where the tasks are called. –  Łukasz 웃 L ツ Jan 16 '12 at 8:11
add comment

The benefit is not being forced to catch or declare them.

I'm not convinced that not finding data during user searches is exceptional, particularly at the SQL level. Turning that into a checked exception amounts to using exceptions for generalized flow control. I would consider that an anti-pattern to be avoided; YMMV.

Many SQL-related errors are code-related; IMO it's better to fail fast--during development.

share|improve this answer
add comment

Your Answer


