Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception Handling

 
Deepika Joshi
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I need to confirm my approch for checked exceptions e.g SQLException;

My code is in try block & catching the exception,
I am logging the exception & re-throwing RuntimeException.

Can you please comment, if this is good approch or if there are better practice for exception handling...

thanks...
 
Travis Hein
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
that should be ok, I think thats how spring framework does it with their sq client tempate classes.

one thing you might want to do when wrapping checked exceptions to throw unchecked ones, is to stuff the original exception as the parent reference into one you throw


this might allos statck trace of errors to bette display what the source of the unchecked exception is such as to debug it.
 
Yucca Nel
Ranch Hand
Posts: 147
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is how I approach all my exceptions and this is also taken from the approach used in JEE. If it is recoverable by you or someone else then keep it checked. For me SQL exception may not be recoverable as this is thrown lower down and unless you are absolutely sure that you are able to handle and recover completely then should you catch such an exception. Further you may catch such an exception in a runtime exception as a type of exploit to propagate it up higher in the stack where you plan to unwrap it again yourself and maybe rethrow it if you feel that it should be handled up higher. Personally I use runtime exceptions in the following scenarios... an exploit of c contract as defined by my javadoc to how my method should be used and alternatively if i plan to wrap a checked exception to bubble it up the stack without making each layer have to catch it. I also tend to wrap all exceptions that I know nothing about and may not be able to recover from (when using a borrowed api) in a runtime exception that I give very clear reasons for in javadoc for the reasons that this exception is thrown.

To recap:

- catch exceptions you can recover from
- throw runtime exceptions for abuse of your API
- use runtime exception as a wrapper to bubble an exception without coding verbose throws clauses to users who may not be able to recover for the same reasons that you were not.
- unwrap wrapped exceptions higher up if you think they are recoverable higher up.
- Use a very well documented runtime exception (like system exception) to end the application if you simply can not deal with the exception and dont expect anyone else to (perhaps the exception was not clear enough to you).

Regards Yucca
 
Deepika Joshi
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks Travis Hein for your reply & I am doing almost same (throw new RuntimeException(ex));
Yucca Nel I am not able to understand "throw runtime exceptions for abuse of your API",
but thanks for in depth reply.

your replies are helpful....
 
Yucca Nel
Ranch Hand
Posts: 147
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deepika Joshi wrote:thanks Travis Hein for your reply & I am doing almost same (throw new RuntimeException(ex));
Yucca Nel I am not able to understand "throw runtime exceptions for abuse of your API",
but thanks for in depth reply.

your replies are helpful....


Abuse of your API means that you make a contract for yr API and state it in javadoc such as... Method must be called with a parameter containing a name that starts with the letter "A". You then proceed to do a validity check to see if the caller of yr code obeys the contract and throw an appropriate runtime exception like NameNotStartWithAException because the user of yr code did not provide a name beginning with "A". This should be familiar to you as most of runtime exceptions in the JSE JDK are thrown for similiar reasons like trying to divide by 0 or invoking a method on null. You may find Joshua Blochs book on effective java explains this a bit better.
 
Deepika Joshi
Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot for your reply... if someone is not following the contract (abuse of API) ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic