524

In C#, I can use the throw; statement to rethrow an exception while preserving the stack trace:

try { ... } catch (Exception e) { if (e is FooException) throw; }

Is there something like this in Java (that doesn't lose the original stack trace)?

Improve this question
5
  • 5
    Why do you think it looses the original stacktrace? The only way to loose it when you throw new SomeOtherException and forget to assign the root cause in the constructor or in initCause(). Commented Jul 8, 2009 at 12:34
  • 5
    I believe this is how the code behaves in .Net, but I'm no longer positive. It might be worthwhile to either look it up somewhere or run a small test. Commented Jul 8, 2009 at 15:03
  • 13
    Throwables don't get modified by throwing them. To update the stack trace you have to call fillInStackTrace(). Conveniently this method gets called in the constructor of a Throwable. Commented Jul 27, 2012 at 0:17
  • 66
    In C#, yes, throw e; will lose the stacktrace. But not in Java. Commented Apr 22, 2013 at 13:42
  • Some doc from Oracle about exceptions with Java 7 : Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking Commented Jul 8, 2014 at 8:47

9 Answers 9

Reset to default
707 
catch (WhateverException e) { throw e; }

will simply rethrow the exception you've caught (obviously the surrounding method has to permit this via its signature etc.). The exception will maintain the original stack trace.

Improve this answer
Sign up to request clarification or add additional context in comments.

10 Comments

Hi, InterruptedException e gives an unhandled Exception message when I add the throw e line. Not so if I replace it with the broader Exception e. How should this be done properly?
In Java 7 compiler for such rethrow is more inteligent. Now it works fine with specific "throws" exceptions in containing method.
@James If you catch(Exception e) { throw e; } that will be unhandled. If you catch(InterruptedException ie) { throw ie; } it will be handled. As a rule of thumb, don't catch(Exception e) - this isn't pokemon, and we don't want to catch 'em all!
@corsiKa It's not necessarily true that you don't want to "Catch 'em all", it's just a different use case. If you have a top-level loop or event handler (for instance, inside a thread's run) if you don't catch at least RuntimeException and log it, you will often miss the exception altogether AND silently break out of an important loop for what is often a one-time failure. It's also really good for plugin functionality where you don't know what additional code might do or throw... For top-down uses like these catching Exception is often not only a good idea but a best practice.
@CorsiKa I mentioned it because the app I work on had a few threads that were randomly eating exceptions. Any thread you don't want to break out of silently should have a catch Exception at the top, and you might want to consider that there are a lot of developers who aren't in your exact situation--many programmers work with threads, not all use frameworks to abstract them--and some write their own frameworks.
|
92

You can also wrap the exception in another one AND keep the original stack trace by passing in the Exception as a Throwable as the cause parameter:

try { ... } catch (Exception e) { throw new YourOwnException(e); }
Improve this answer

4 Comments

I would also advise on adding a message alongside, using throw new YourOwnException("Error while trying to ....", e);
this is what I was looking for, especially the version from the first comment where you can pass your own message
This show the error message correctly but the stack trace shows the error line as line with 'throw new.......(e)' not the original line that caused exception.
This only works if YourOwnException is properly set up, see the 4 public constructors on RuntimeException which call super.
89

I would prefer:

try { ... } catch (FooException fe){ throw fe; } catch (Exception e) { // Note: don't catch all exceptions like this unless you know what you // are doing. ... }
Improve this answer

8 Comments

Definitely proper in Java to catch specific exceptions than generic and checking for instance of. +1
-1 because you should never catch plain "Exception" unless you know what you're doing.
@Stroboskop: true, but to answer it's best to use the same (similar) code as in the question!
Sometimes catching all exceptions is ok. Such as when you are writing a test case. Or for logging purposes. Or in the main where not catching means crashing.
@JohnHenckel and others: Valid points inded. I updated the question to make it clear that catching Exception is typically not the right thing to do, in most (but not all) cases.
|
21

In Java is almost the same:

try { ... } catch (Exception e) { if (e instanceof FooException) throw e; }
Improve this answer

5 Comments

I would add a specific catch for FooException
In this specific case I agree, but adding a specific catch may not be the right choice - imagine you have some common code for all exceptions and after, for a particular exception, rethrow it.
@MarkusLausberg But finally doesn't catch exceptions.
Yes, but this was not the question.
As you mention in the comment, this code would only make sense if you have more code that uses e after the if. Otherwise, it's just not quite right to use instanceof. You could add an ellipsis or comment stating that.
15

In Java, you just throw the exception you caught, so throw e rather than just throw. Java maintains the stack trace.

Improve this answer

Comments

7

Stack trace is preserved if you wrap the caught exception into another exception (to provide more info) or if you just rethrow the caught exception.

try{ ... }catch (FooException e){ throw new BarException("Some useful info", e); }
Improve this answer

Comments

6

something like this

try { ... } catch (FooException e) { throw e; } catch (Exception e) { ... }
Improve this answer

Comments

6 
public int read(byte[] a) throws IOException { try { return in.read(a); } catch (final Throwable t) { /* can do something here, like in=null; */ throw t; } }

This is a concrete example where the method throws an IOException. The final means t can only hold an exception thrown from the try block. Additional reading material can be found here and here.

Improve this answer

1 Comment

It doesn't have to be final. See docs.oracle.com/javase/7/docs/technotes/guides/language/… and stackoverflow.com/a/6889301/131160
3

I was just having a similar situation in which my code potentially throws a number of different exceptions that I just wanted to rethrow. The solution described above was not working for me, because Eclipse told me that throw e; leads to an unhandeled exception, so I just did this:

try { ... } catch (NoSuchMethodException | SecurityException | IllegalAccessException e) { throw new RuntimeException(e.getClass().getName() + ": " + e.getMessage() + "\n" + e.getStackTrace().toString()); }

Worked for me....:)

Improve this answer

2 Comments

Avoid self-made extraction of info about e. Better pack the original exception with throw new RuntimeException("Some usefull info", e). In the string, gives somes usefull info that are missing in e, for example some important arguments of your method, info about the context, or whatever will help debugging.
Please don't do this : 1. You are packing checked exception in RuntimeExceptions. 2. You are loosing informations

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.