Why can I "fake" the stack trace of an exception in Java?

Question

If I run the following test, it fails:

public class CrazyExceptions {
    private Exception exception;

    @Before
    public void setUp(){
        exception = new Exception();
    }

    @Test
    public void stackTraceMentionsTheLocationWhereTheExceptionWasThrown(){
        String thisMethod = new Exception().getStackTrace()[0].getMethodName();
        try {
            throw exception;
        }
        catch(Exception e) {
            assertEquals(thisMethod, e.getStackTrace()[0].getMethodName());
        }
    }
}

With the following error:

Expected :stackTraceMentionsTheLocationWhereTheExceptionWasThrown
Actual   :setUp

The stack trace is just flat out lying.

Why isn't the stack trace rewritten when the exception is thrown? I am not a Java dev, and maybe I'm missing something here.

I dont know if 6 years ago we could set the stack trace "cause" of the exception, but it is better to use this after creating the new exception and before throwing it: Exception.initCause(Throwable), where you configure the cause stacktrace with setStackTrace(). — Aquarius Power, May 30 '16 at 06:50

mhaller · Accepted Answer · 2009-11-08T15:05:02.940

21

The stack trace is created when the exception is instantiated, not when it is thrown. This is specified behaviour of the Java Language Specification

20.22.1  public Throwable()

This constructor initializes a newly created Throwable object with null as
its error message string. Also, the method fillInStackTrace (§20.22.5) is
called for this object. 

....

20.22.5  public Throwable fillInStackTrace()

This method records within this Throwable object information about the
current state of the stack frames for the current thread.

I don't know why they did it that way, but if the specification defines it like that, it is at least consistent on all the various Java VMs.

However, you can refresh it by calling exception.fillInStackTrace() manually.

Also note that you should use Thread.currentThread().getStackTrace() instead of using new Exception().getStackTrace() (bad style).

edited Nov 08 '09 at 15:05

answered Nov 08 '09 at 14:59

mhaller

14,122
1
42
61

I didn't use `Thread.currentThread().getStackTrace()` because `Thread.currentThread().getStackTrace()[0].getMethodName` is always `getStacktrace`... – R. Martinho Fernandes Nov 08 '09 at 15:08
+1 for pointing out the manual `fillInStackTrace` thing. In C# we get that behavior by default and we can simply `throw;` when we need to keep the stack trace when rethrowing. – R. Martinho Fernandes Nov 08 '09 at 15:08
It's `getStackTrace()[1]`, nothing more. – mhaller Nov 08 '09 at 15:27
3

@mhaller, no `[1]` doesn't get you the current method name in JDK 1.5, it is [2] (there is an extra internal method call). So getStackTrace is great to get a view of the stack, lousy if you care where you are (who says it won't change in another version to 3 or back to 1). – Yishai Nov 08 '09 at 15:43

score 10 · Answer 2 · answered Nov 08 '09 at 15:03

10

The stacktrace of the exception is filled in at creation time of the exception. Otherwise it would be impossible to catch an exception, handle it and rethrow it. The original stacktrace would get lost.

If you want to force this you have to call exception.fillInStackTrace() explicitly.

answered Nov 08 '09 at 15:03

tangens

39,095
19
120
139

1

In C# we get that behavior by default and we can simply `throw;` when we need to keep the stack trace when rethrowing. That's why I got confused. – R. Martinho Fernandes Nov 08 '09 at 15:09
-1: We know from .NET that this is not the case. There is certainly some rationale for when the stack trace is captured, but it's not because it can't be managed when captured by a `throw e;` statement. – Sam Harwell Nov 08 '09 at 16:33
@280Z28, the point is that in java there would be no way, as it has no such language construct as throw;. – Yishai Nov 08 '09 at 17:13
@Yishai: right, but keep in mind we're talking about the language design itself, so *if* this was the problem, they could have gotten around it. They might have called it `rethrow`, but whatever it became it's obvious they would need the ability to rethrow the exception without changing the stack trace. – Sam Harwell Nov 08 '09 at 17:28
2

@280Z28, the question wasn't is there some way around it by changing the language, but why java doesn't set the stacktrace at the time it was thrown. It doesn't because it would have no mechanism to rethrow and keep the old stack trace. Instead it has fillInStackTrace if you need to reset the stack trace. It is a different design. – Yishai Nov 08 '09 at 17:38

duffymo · Answer 3 · 2009-11-08T15:04:52.557

1

Because you didn't ask that that stack trace be rewritten. It was set when you created it in the setUp method, and you never did anything to alter it.

The Exception class doesn't give you any opportunity to set the method name; it's immutable. So there's no way that I know of where you could re-set the method name, unless you wanted to resort to something heinous like reflection.

Your @Test annotation doesn't tell me if you're using JUnit or TestNG, because I can't see the static import, but in either case you can run a test to see if a particular exception is thrown by using the "expected" member in the @Test annotation.

edited Nov 08 '09 at 15:04

answered Nov 08 '09 at 14:58

duffymo

305,152
44
369
561

I'm using jUnit, but I wasn't trying to test for exceptions being thrown. I used the test just to illustrate my question. – R. Martinho Fernandes Nov 08 '09 at 15:01
I'm not sure what the question is: "How do I alter the method from a stack trace?" – duffymo Nov 08 '09 at 15:06

score 1 · Answer 4 · answered Nov 08 '09 at 16:19

You wouldn't want throwing an exception to alter the stack track or you couldn't re-throw an exception safely.

public void throwsException() {
    throw new RuntimeException();
}

public void logsException() {
    try {
        throwsException();
    } catch (RuntimeException e) {
        e.printStrackTrace();
        throw e; // doesn't alter the exception.
    }
}

@Test
public void youCanSeeTheCauseOfAnException(){
    try {
        logsException();
    } catch(Exception e) {
        e.printStrackTrace(); // shows you the case of the exception, not where it was last re-thrown.
    }
}

score 0 · Answer 5 · edited Jan 25 '19 at 13:40

I think the assumption is that you won't be instantiating an exception unless you are in the process of throwing it, so why pay the price to get the stack trace twice?

It would be difficult to recreate the stack trace while throwing it, as that is just sending the object out.

The exception should be fully setup before the throw, so part of the instantiation is to get the stack trace.

UPDATE:

You can call fillInStackTrace() to resolve this.

score 0 · Answer 6 · answered Nov 08 '09 at 20:18

0

The stack trace in the exception corresponds to the "new" operation, nothing else.

answered Nov 08 '09 at 20:18

Thorbjørn Ravn Andersen

73,784
33
194
347

Why can I "fake" the stack trace of an exception in Java?

6 Answers6

Linked