• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Exception handling in Spring

 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx Lasse.
 
Reghu Ram Thanumalayan
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
reply
    Bookmark Topic Watch Topic
  • New Topic