CODEWITHSUNDEEP
javaoracle-databasespringplsqljdbctemplate
ziggy
ziggy

Reputation: 15876

Spring's implementation of Exception Handling in JDBCTemplate

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?

Upvotes: 1

Views: 9824

Answers (3)

gpeche
gpeche

Reputation: 22514

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.

Upvotes: 2

Dave Newton
Dave Newton

Reputation: 160261

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.

Upvotes: 2

Cjxcz Odjcayrwl
Cjxcz Odjcayrwl

Reputation: 22867

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.

Upvotes: 4

Related Questions