Rethrowing exception?

[Gurumurthy Ramamurthy]

What is the meaning of rethrowing exception?
What happens during rethrowing exception?
How the exception is getting propagated?

Thanks,
Guru

[Matthew Brown]

When you catch an exception, it's possible to rethrow it. This is just the same as if you hadn't caught it in the first place - the exception will continue to bubble up through the layers until it reaches some other code that catches it (or it reaches the top of the stack and the program exits).

So why would you do this? Well, it means you have temporary access to the exception at the point where you caught it. One situation I've used this in is where I want to log the fact that an error has occurred, but the real error handling is happening at a higher level. You'd only do this, though, if this local logging could add something useful that the higher level error handling doesn't know about.

For example:

...
try {
    riskyOperationThatCanThrowAnException(target);
}
catch (IOException ex) {
    Logger.log("Exception while carrying out risky operation on " + target);
    throw ex;
}

[Campbell Ritchie]

Beware of logging and rethrowing together; you may end up logging the same Exception twice.
Some exceptions must be rethrown, eg this one, if they are caught.
You can probably find something useful in the Java Tutorials.

[Matthew Brown]

Campbell Ritchie wrote:Some exceptions must be rethrown, eg this one, if they are caught.

Technically, not an exception, though (although you can catch it). Or, at least, not an Exception. So if you only catch Exception and subclasses (which you should probably be doing anyway) it's not a problem.

[Jeff Verdegan]

Also, just rethrowing it as-is is less common than wrapping it in a more layer-appropriate exception and throwing that.

For instance, if client code of a higher-level architectural layer doesn't need to see low-level IOExceptions, we may wrap it in an Exception that describes the error in terms that make sense for that layer.

public void generateReport() throws ReportingException {
  try {
    ...
  }
  catch(IOException e) {
    throw new MissingReportDataException(e); // assume MissingReportDataException is a subclsass of ReportingException
  }
}

The caller of generateReport() doesn't know or care about the internal details of how that method operates. If something fails, it wants an exception appropriate to that layer (ReportingException), and it may or may not be interested in what specifically went wrong (not all the necessary data was available). So we define a class called ReportingException, and throw it or one of its subclasses.

We wrap the original IOException to be thrown with the reporting exception so that all the information is still available, possibly to code that might ultimately handle the exception, but more likely just so that the full stack trace gets logged, and the maintenance developer can see all the details of what went wrong.

[Brian Burress]

Also, keep aware of the type of application while performing your exception handling. I think you need to always make sure there is appropriate logging of the original exception for debugging purposes. In some applications (like a web application) you may want to hide any specifics of the exception so wrapping the original exception may not be the best as you may end up revealing details about your implementation which a hacker could exploit.

[Stephan van Hulst]

Before Java 1.7, I've also used it on rare occasions where I needed the same exception handling for a myriad of disjoint exceptions. I'd catch the most specific common super-type, and then rethrow the exceptions that I don't want to handle.

[Jeff Verdegan]

Stephan van Hulst wrote:Before Java 1.7, I've also used it on rare occasions where I needed the same exception handling for a myriad of disjoint exceptions. I'd catch the most specific common super-type, and then rethrow the exceptions that I don't want to handle.

What's new in 7? (Just a keyword or two is fine, so I know what to search for.)

[Joanne Neal]

Jeff Verdegan wrote:

Stephan van Hulst wrote:Before Java 1.7, I've also used it on rare occasions where I needed the same exception handling for a myriad of disjoint exceptions. I'd catch the most specific common super-type, and then rethrow the exceptions that I don't want to handle.

What's new in 7? (Just a keyword or two is fine, so I know what to search for.)

I can't remember the terminology, but you can catch multiple exceptions with a single catch

try {
  .
  .
} catch (MyException | YourException | IOException e) {
}

Here you go. Apparently there isn't a fancy name for it.

[Stephan van Hulst]

I don't know what they call it, but you can catch multiple unrelated exceptions in a single catch clause now:

catch (IOException | InterruptedException ex) {
    logger.log(ex);
}

[edit]

Hah, Joanne was quicker.

[Joanne Neal]

Stephan van Hulst wrote:Hah, Joanne was quicker.

i even managed to edit my reply twice before you replied

[Stephan van Hulst]

That's okay, you were beaten at the "day of the week" question by two people ;P

[Jeff Verdegan]

Sweet. I've been wishing for something like that for a while. Apparently I wasn't the only one.

Thanks guys!

[Joanne Neal]

Stephan van Hulst wrote:That's okay, you were beaten at the "day of the week" question by two people ;P

I was hoping you hadn't seen that.

[Campbell Ritchie]

I hadn’t . . . but I shall make sure to have a good look. Now if Rob Spoor had been beaten like that, that would be even better

[Stephan van Hulst]

Yeah, Rob is a beast.

[Rob Spoor]

And don't forget it!