Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Why we throw exception as we have try and catch to catch the Exception ?  RSS feed

 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As we have already use try catch to catch the exception then why we Throw the exception and in which case we do so ?
 
Pushkar Choudhary
Rancher
Posts: 425
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Couldn't understand your question correctly. Are you talking about a situation like the one given below? -
 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
yes correct
 
Rob Spoor
Sheriff
Posts: 21133
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sometimes you don't want to handle an error in a method, but let the calling method worry about that. How else would the calling method know that something went wrong?
Never mind the above

There are two main reasons for throwing a different type of exception:
- you implement an interface or extend a class and the method signature only allows certain types of exceptions to be thrown. The exception that is being caught is not one of them. You have no choice but to catch it and from another exception. I've seen quite a few examples where programmers catch checked exceptions (e.g. IOException) and wrap it into a RuntimeException because the method does not allow any checked exceptions at all.

- in your business logic it makes more sense to throw another exception; in essence, you're hiding the true identity of your exception, because this is considered to be an implementation detail. For instance, catching an IOException and wrapping into a UserException (made up name, it just happens to match one from CORBA. Don't go looking for it )

Either case, it's a good idea to set the original exception as the cause of the new exception. Either do this by passing it as an argument to the constructor of the new exception, or call initCause after creating the new exception:
 
Pushkar Choudhary
Rancher
Posts: 425
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with Rob. In addition, I think it also depends on whether you want to do anything specific before throwing the exception, like logging it.

If you want to log the exception or do some other computation, then it makes sense to enclose the code in a try-catch block. Otherwise, if you don't want to do anything with the exception, then you can let it be thrown automatically using the throws.
 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is correct that whenever we need to throw exception from one layer to another , then we have to throw Exception instead of try catch ?

sometimes the exception can be propogated from more than 1 layers..like DB Layer to Hibernate Layer or GI Layer ??

Would you elebroate on this point ?
 
Campbell Ritchie
Marshal
Posts: 56530
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't understand the last question. If you need to pass an Exception from one method to another, you need to throw some sort of Exception. From one layer to another, there may be other ways than Exceptions to pass the error message, but the Java custom is to try Exceptions first.
If you are throwing an Exception and catching it in the same method, how is that different from using an if-else? Apart from poor performance, that is?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!