No stack for a NullPointerException

[Nicolas]

Hi all,
I have been developing in Java for a while now, but have never
encountered this :

In a try block, an NullPointerException is thrown. I catch it and call
printStackTrace() to display the message and mostly see the stack.
Problem : none is output in the stream. Only the message is displayed
:

java.lang.NullPointerException

My code is very common :
try{
.... // several checks on null values in this code + processing
}
catch( Exception e ){
e.printStackTrace( pw ); // pw is a PrintWriter
}

I also tried to output the stack in the standard error stream (ie
e.printStackTrace()), but I got the same result.

This is a problem, since I want to know what caused the exception.
Does anyone know what happens ?

Thanks in advance,
Nico

 

[Rhino]

Hi all,
I have been developing in Java for a while now, but have never
encountered this :

In a try block, an NullPointerException is thrown. I catch it and call
printStackTrace() to display the message and mostly see the stack.
Problem : none is output in the stream. Only the message is displayed
:

java.lang.NullPointerException

My code is very common :
try{
... // several checks on null values in this code + processing
}
catch( Exception e ){
e.printStackTrace( pw ); // pw is a PrintWriter
}

I also tried to output the stack in the standard error stream (ie
e.printStackTrace()), but I got the same result.

This is a problem, since I want to know what caused the exception.
Does anyone know what happens ?

Thanks in advance,
Nico

I'm not sure why your stacktrace isn't appearing but I can certainly
understand your frustration at not getting it; it certainly makes problem
solving harder!

Have you tried stepping through the code with a debugger? I've always found
that an excellent technique for finding and solving problems in my code.

I use Eclipse's integrated debugger but I assume the other IDEs have their
own debuggers. If you aren't using an IDE, I imagine you could get a good
add-on debugger without too much difficulty.

That doesn't answer your immediate question about why your stacktrace isn't
appearing but it might help with the bigger issue of solving problems....

Rhino

 

[Andrea Desole]

this is very strange. As Rhino said, you can definitely debug it. If the
code in the try block is too much and you can't esily find the point
where the exception is thrown, using Eclipse you can try to set an
exception breakpoint. This solution, however, doesn't help you if you
need to log your information.
I'm curious. If you are using JDK 1.4 and a debugger maybe you can try
to look at the result of e.getStackTrace(). I can't believe it's empty.

 

[Ryan Stewart]

Hi all,
I have been developing in Java for a while now, but have never
encountered this :

In a try block, an NullPointerException is thrown. I catch it and call
printStackTrace() to display the message and mostly see the stack.
Problem : none is output in the stream. Only the message is displayed
:

java.lang.NullPointerException

My code is very common :
try{
... // several checks on null values in this code + processing
}
catch( Exception e ){
e.printStackTrace( pw ); // pw is a PrintWriter
}

I also tried to output the stack in the standard error stream (ie
e.printStackTrace()), but I got the same result.

This is a problem, since I want to know what caused the exception.
Does anyone know what happens ?

There is this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4292742

 

[Nicolas]

There is this bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4292742

Hi all,

Thanks for your replies. My problem is a bit more complicated than
what I presented.

In fact, we encounter a bug on production we're not able to reproduce
development or qa environments (on same data sets). We considered
using a debugger (or even many System.out.println() in the code), but
as we can't get to reproduce the exception on development envt, it's
no use. The NPE is only thrown sometimes on production (not even twice
on the same data...), which makes it quite hard to figure out 8| ...

The only way to find out the problem is getting as much information
about the exception when it happens on production. I already output
the data items that create the bug, but processing them unitely
doesn't throw anything. That's why the trace would be a hell of a clue
!!!

I know it sounds like like a newbie problem ( it works here but not
there.. ) but that's unfortunately the way it is.

I checked the sun bug page Ryan sent, and that may be the trouble.
I'll try to investigate further down that path, see if there are
workarounds.

By the way, we use this version of java on production :

java version "1.4.1.07"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1.07-040312-13:53)
Java HotSpot(TM) Server VM (build 1.4.1
1.4.1.07-040312-15:24-PA_RISC2.0 PA2.0 (aCC_AP), mixed mode)

Thanks for your help,
Nico

 

[Thomas Schodt]

In fact, we encounter a bug on production we're not able to reproduce
development or qa environments (on same data sets). We considered
using a debugger (or even many System.out.println() in the code), but
as we can't get to reproduce the exception on development envt, it's
no use. The NPE is only thrown sometimes on production (not even twice
on the same data...), which makes it quite hard to figure out 8| ...

The only way to find out the problem is getting as much information
about the exception when it happens on production. I already output
the data items that create the bug, but processing them unitely
doesn't throw anything. That's why the trace would be a hell of a clue
!!!

I know it sounds like like a newbie problem ( it works here but not
there.. ) but that's unfortunately the way it is.

I checked the sun bug page Ryan sent, and that may be the trouble.
I'll try to investigate further down that path, see if there are
workarounds.

I have seen OutOfMemory scenarios causing failures
"at random places" - often with a "stack-less" NPE in there somewhere.

Only zeroed in on it after running with -XlogGC:filename

If Runtime.totalMemory() reaches Runtime.maxMemory()
a while before you get a failure...