• Post Reply Bookmark Topic Watch Topic
  • New Topic

precise rethrow of an exception  RSS feed

 
John Smithonian
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am looking at this article:

http://www.theserverside.com/tutorial/OCPJP-Use-more-precise-rethrow-in-exceptions-Objective-Java-7

And I am confused. For example, they have this code, but it makes no sense to me, why would you want to throw OpenException and CloseException when you are catching them already? Surely either you catch an exception, or you throw it, why would you need to do both?

Thanks.
 
Stefan Evans
Bartender
Posts: 1837
10
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear in mind that this is simplified sample code for the purpose of example.
It is not necessarily representative of code you would write in the real world.

The catching and re-throwing of an exception is quite a common (anti)pattern.
You often see the "Catch, log, re-throw" in code.
It should normally only occur if doing so can "add value".

The contrived part of this example is the throwing of the exception.
No you wouldn't write code EXACTLY like this, but you would write code that could produce exceptions (SQLException, IOException, CustomSomethingWentWrongException)
However, for this article, it doesn't matter what exceptions are being thrown, or even who throws them.
This article is demonstrating how you can catch and handle specific exceptions generally (thus minimising the number of catch blocks) while still being able to declare the specific exceptions as being thrown.

So the above code simplifies to this in Java 7



Only one catch block. No repeated code. It's better right?
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The main point of that code is to show that even though you appear to be throwing an Exception the compiler is clever enough to realise that the exception can only be an OpenException, CloseException or RuntimeException. It doesn't make you declare that the method throws Exception.

Their specific example (of logging then rethrowing) is a very bad thing to do because it will likely mean that the same exception will be logged multiple times. I can't actually think of a time when I have wanted to catch an Exception, do something useful and then rethrow the same Exception. I'd be interested to know if anyone else has found it useful to do that, but most situations I can think of are better suited to a finally block.

It is much more common to catch an Exception and then throw a new Exception, passing the original Exception into the constructor as the cause. This allows you to hide an implementation detail without losing information.
 
Campbell Ritchie
Marshal
Posts: 56541
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would suggest you tryyou should be able to read about the catch with multiple Exception types here.
You can throw a different Exception passing the original Exception to its constructor as MJT saysMost Exceptions have a constructor which takes Throwable and all Exceptions are Throwables. If you go through the Java™ Tutorials, you find that is called exception chaining.

A lot of people say it is bad practice to log and to rethrow an Exception because there is a risk of logging the same Exception twice. Also, never throw and catch the same Exception in the same method in real life; that is simply an inefficient way of writing an if‑else. People who write tutorial examples often take shortcuts like that to demonstrate their point, as Stefan Evans has already told you.
 
John Smithonian
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all, I also don't like the idea of catching, logging, and rethrowing.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!