Deciphering Stack Trace that is infused with a lot of JUnit

Question

Please note, this isn't a duplicate of this.

I have been writing some code that is run as a JUnit. I read the thread linked above, which talks about how the location of an error in a stack trace is normally closest to the bottom. However, because my code is being run as a JUnit test, the stack trace is infused with a lot of what I think is a result of the code being run as a Unit test, so the error can not be directly traced to the bottom of the stack trace, like what the post above says. (<--Why it isn't a duplicate).

The following is the stack trace that I get after running code.

java.lang.NullPointerException
    at API.ItemFetcher.<init>(ItemFetcher.java:39)
    at API.MarketConstants.<clinit>(MarketConstants.java:24)
    at API.ItemFetcher.setOtherMonetaryValues(ItemFetcher.java:153)
    at API.ItemFetcher.<init>(ItemFetcher.java:53)
    at Tests.Tests.test(Tests.java:14)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

The structure of my code is as follows

-src
  -API
    -Item.java
    -ItemFetcher.java
    -MarketConstants.java
    -IrrelevantFolder
  -Tests
    -Tests.java

Where should I look in the code, based on the stack trace, for the error? I'm not 100% sure where to look because of all of the JUnit stuff in the stack trace. Like I said before, I have read other SO threads on this but it hasn't been covered before.

Start by looking at `Tests.Tests.test`, line 14. That line in your test is causing the failure. — ajb, Jan 03 '16 at 06:35
For a NullPointerException, you typically want to look for an *uninitialized object* being accessed at the *first line* in the traceback: `API.ItemFetcher.(ItemFetcher.java:39)`. Then work backwards to determine where the object variable was *supposed* to be initialized. — paulsm4, Jan 03 '16 at 06:40
To whomever down voted this. Please explain **why** you down voted and how my post could be better. — intboolstring, Jan 03 '16 at 06:49
You are asking "how do I interpret a stack trace". There is a canonical question for this. — Raedwald, Jan 03 '16 at 08:10
Possible duplicate of [What is a stack trace, and how can I use it to debug my application errors?](http://stackoverflow.com/questions/3988788/what-is-a-stack-trace-and-how-can-i-use-it-to-debug-my-application-errors) — Raedwald, Jan 03 '16 at 08:10
Despite your protest that this is not a duplicate, a denial for which you provide no justification, this *is* a duplicate of the canonical question about stack traces. — Raedwald, Jan 03 '16 at 08:12
@Raedwald. Read the update to my question. It explains **why** the solution provided in the other question doesn't work. — intboolstring, Jan 03 '16 at 16:52
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/99604/discussion-between-intboolstring-and-raedwald). — intboolstring, Jan 03 '16 at 17:09

score 3 · Answer 1 · answered Jan 03 '16 at 06:34

If you look at the root cause in the stack trace it states that the NullPointerException occurs at API.ItemFetcher.<init>(ItemFetcher.java:39). This means that at line 39, inside the ItemFetcher class, there is a NullPointerException occurring.

Keep in mind that JUnit just calls YOUR existing classes/methods. So always look for where your code is in the stack trace.

score 0 · Accepted Answer · edited May 23 '17 at 12:09

A stack trace is powerful tool, and the post you cited gives very good advice about how to use it.

But a stack trace is ONLY a "tool". You've got to do the work. You've got to think logically.

You must not say nonsense like "line 'ItemFetcher.java:xyz' always used to work, so it can't possibly be the problem". That's when I voted you down ;) You've deleted that remark (thank you!), and I've retracted my down vote.

Here's how I'd approach the problem:

Yes, you've got a lot of "JUnit" stuff in your traceback.

Q: How can JUnit cause the problem?

A: It probably can't. Like RamV13 (correctly!) pointed out, "Keep in mind that JUnit just calls YOUR existing classes/methods. So always look for where your code is in the stack trace".

So, for starters, I'd look elsewhere in the code, and simply ignore the JUnit lines.
As RamV13 also pointed out, "ItemFetcher.java:39" is where "your code" starts. That's absolutely a good place to start looking.
Q: What are you looking for?

A: If you had a "DivideByZero" error, you'd look for an arithmetic expression that might evaluate to a "0" denominator. If you had an IOException", you'd be looking for an "open()", a "read()" or a "write()".

In this case, you've got a "NullPointerException".

So you're looking for AN UNINITIALIZED VARIABLE.
Q: What variable?

The best place to look is the exact line where the NullPointerException occurred:

java.lang.NullPointerException
    at API.ItemFetcher.<init>(ItemFetcher.java:39) 
    <-- Your problem is an uninitialized variable at line 39!

Q: Why is it uninitialized?

That's for you to figure out. Look backwards in the code (perhaps even going back as far as ItemFetcher.java:39) and see where it should have been initialized.

Then fix it :)

'Hope that helps!

Now I realized some more. The reason it wasn't working this time but working before is because I had a constructor that was in a TODO state, which was causing an error. Because of that, JSoup was throwing a null pointer exception because it was searching for something that doesn't exist. — intboolstring, Jan 03 '16 at 21:18

Deciphering Stack Trace that is infused with a lot of JUnit

2 Answers2