• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why would I ever want to rethrow an exception?  RSS feed

 
Paul Mrozik
Ranch Hand
Posts: 117
Chrome Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I still don't feel exceptions, here's a quote from TIJ:

Sometimes you'll want to rethrow the exception that you just caught, particularly when you use Exception to catch any exception. Since you already have the reference to the current exception, you can simply rethrow that reference:





Now, why on earth would I ever want to rethrow an exception? It does say that it might be useful when I use Exception to catch any exception, but...why? Is this even used? Can someone give me an example please?

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
you should not stop an exception's propagation down the call chain unless you've actually handled it. That is, fixed the problem or found a suitable replacement for the action you were attempting. Merely catching an exception doesn't fix anything. That's not what the exception mechanism is for.

So if you want to take some action on an exception--such as logging that it occurred, or updating some metrics--but you're not in a position to actually address the underlying problem at that point, you rethrow it, so it can continue on its way to a context where it can be dealt with.

Having said that, simply rethrowing the same exception is fairly uncommon. It's more common to wrap it in something more suitable for the layer in which we're currently working. For example, user of our class might not need to know or care about whether we're using a DB or a file or something else to store data. All he cares about is that we either succeed at storing it or fail to do so. So we might to something like:

 
Paul Mrozik
Ranch Hand
Posts: 117
Chrome Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:You should not stop an exception's propagation down the call chain unless you've actually handled it. That is, fixed the problem or found a suitable replacement for the action you were attempting. Merely catching an exception doesn't fix anything. That's not what the exception mechanism is for.

So if you want to take some action on an exception--such as logging that it occurred, or updating some metrics--but you're not in a position to actually address the underlying problem at that point, you rethrow it, so it can continue on its way to a context where it can be dealt with.

Having said that, simply rethrowing the same exception is fairly uncommon. It's more common to wrap it in something more suitable for the layer in which we're currently working. For example, user of our class might not need to know or care about whether we're using a DB or a file or something else to store data. All he cares about is that we either succeed at storing it or fail to do so. So we might to something like:



I'll read what you said again tomorrow morning to get a fresh perspective. I see how it works, just don't know how I would use it, but maybe it'll come once I read/write more code. I'm assuming that there would be an UPDATE attempt in the try clause, which would throw an SQLException upon failure. Why not just do something like:



instead of the rethrow? The user might not care, but I'm sure they'll understand.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Mrozik wrote:Why not just do something like:



instead of the rethrow? The user might not care, but I'm sure they'll understand.


You mean why throw a different exception? As I stated: Because the fact that it's a SQLException vs. an IOException vs. something else may not be relevant or appropriate for the caller of your method to know about. If he doesn't know or care about what specific mechanism you're using to store the data, he also shouldn't need to know or care about--shouldn't need to trouble himself with--implementation-specific exceptions.

An important part of OO programming is hiding details that aren't relevant.
 
Paul Mrozik
Ranch Hand
Posts: 117
Chrome Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:

You mean why throw a different exception? As I stated: Because the fact that it's a SQLException vs. an IOException vs. something else may not be relevant or appropriate for the caller of your method to know about. If he doesn't know or care about what specific mechanism you're using to store the data, he also shouldn't need to know or care about--shouldn't need to trouble himself with--implementation-specific exceptions.

An important part of OO programming is hiding details that aren't relevant.


I understand what you're saying, I'd just have to see this mechanism used somewhere in real code or find a need for it myself to get a feel for it. Thanks.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!