aspose file tools*
The moose likes Other Application Frameworks and the fly likes Exception handling in Spring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Exception handling in Spring" Watch "Exception handling in Spring" New topic
Author

Exception handling in Spring

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

I read some time back that Exceptions thrown from Spring fraework are all RuntimeException. What is the reason of using unchecked exceptions. If Runtimetime Exception is thrown it will go all the way to the client without being caught,right? Is that a good practice. Thanks


Groovy
Reghu Ram Thanumalayan
Ranch Hand

Joined: Oct 21, 2003
Posts: 193
Hi Pradeep,

If Runtimetime Exception is thrown it will go all the way to the client without being caught,right?


I did not understand this part ? What do you mean by client here ? Why cannot runtime exceptions be caught ?


Cheers,<br />Reghu Ram T<br /> <br />SCJP 1.4 - 98 %, SCBCD 1.3 - 94 %, SCMAD 1.0 - 92 %
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
I read some time back that Exceptions thrown from Spring fraework are all RuntimeException. What is the reason of using unchecked exceptions? If Runtimetime Exception is thrown it will go all the way to the client without being caught,right? Is that a good practice?

Let's take the JDBC API as an example since it makes heavy use of checked exceptions (java.sql.SQLException):
If Statement#executeQuery() throws an SQLException, how are you going to recover from that?
It's all too common for libraries to force the immediate client code to catch all sorts of exceptions that might be thrown even though that client code has no way of *handling* that exception--other than re-throwing it.

That's why Spring, for example, uses RuntimeExceptions. The API still declares which exceptions may be thrown so you can catch those you're interested in -- those you know how to handle -- and the rest are bubbled upwards all the way until the layer of your code that knows what to do with the exception. And you don't have to do "try { ... } catch (Exception e) { throw e; }" all the time.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Thanx Lasse.
Reghu Ram Thanumalayan
Ranch Hand

Joined: Oct 21, 2003
Posts: 193
Hello Lasse,
So it is perfectly alright to catch the runtime exception in the top layer of the code right so that client just doesnt hang up ?
louise rochford
Ranch Hand

Joined: Apr 04, 2002
Posts: 119
Reghu,
Could do. You'd usually handle all the exceptions you expect, set up messages etc & send the user to the appropriate page (probably using some standard mechanism - I'm not sure how the MVC part of Spring does this).
There's nothing to stop you from wrapping doing a final catch for all exceptions, logging the problem & sending the user to a default 'safe' error page. This ensures that the user never sees a stack trace or other nasty message.

The benefit of run time exceptions is that you could e.g. ignore that fact that a Spring DataAccessException has been thrown by a database query in the majority of your code stack, except for maybe in the top-layer, where you might log the user out & give them a message telling them to contact the database team (or whatever is appropriate).
If they're checked exceptions the rest of your code has to either handle the exceptions or throw them - both of which can lead to messy code.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Lasse did an excellent job of answering this question before I even saw it.

Lasse's right...a lot of exceptions thrown around in Java apps (SQLException and RemoteException come to mind) usually indicate a problem so serious that you can't possibly recover. Instead of forcing you to catch or rethrow these exceptions everywhere, Spring catches them for you, then rethrows them as some subclass of RuntimeException. You can catch them if you'd like or you can ignore them.

Once you get the hang of it, there's a great freedom in being able to write code without worrying about what exceptions you may need to catch. Sure, your IDE may make it easy to generate a try/catch block, but regardless of who writes the try/catch block, now your code is cluttered with code to handle exceptions that cannot be gracefully dealt with.


Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
 
 
subject: Exception handling in Spring