Better Java error messages

D

DJ Majestik

Newbie question here,

I have been going through Java error messages sent to me at work here
to get acclimated to the Java language (PHP, .NET programmer in the
past).

Is there any way of seeing what variables have been set by the user
using the application? In other words, if someone submits a form and
there is a first name and last name field, can I see in my error
display those variables? So with the backtrace, all the "global"
variables would be displayed? I might then see a NullPointerException
because someone didn't enter the first name, and I did not catch it.

If not, is there some links on the web explaining how to better read a
Java backtrace and make some sense out of it? I see a lot of
NullPointerExceptions, and although I know all the things that could be
causing it, it is hard to pinpoint sometimes the exact source of the
error (even with the line numbers).

If anyone has any ideas, would love to hear them. Thanks!

JJ
 
T

Thomas Weidenfeller

DJ said:
Is there any way of seeing what variables have been set by the user
using the application?

Connect a debugger to the application.
If not, is there some links on the web explaining how to better read a
Java backtrace and make some sense out of it?

There is nothing magic about it. You just see the call-stack from the
top to the bottom. If compiled with that information you also get the
line numbers where things (method invocations or NPE) happened.

Simply follow variable assignment in your source code down along the
line of what in printed in the call stack.

/Thomas
 
D

DJ Majestik

Can't connect a debugger to it, because these are emails with the stack
trace that come in.

The call-stack points out the location of the error (sometimes) but
doesn't show the state the user is in. I am then trying to guess what
the user did on the page to cause the error. I was just wondering if
there was something so that I could see something like record_id=100
showing that the user viewed record id 100, vs. not having that and
trying to guess at which record caused the error.

I am new so it probably is something I don't fully understand yet.
Sorry,

JJ
 
J

John Currier

No, you understand it. Many years ago I (with some co-workers)
developed exactly what you're talking about for OS/2 programs, even
dealing with the 32bit->16bit and back thunking layers.

The only context associated with a Java stacktrace entry is the name of
the class and (optional) line number. Usually people enable some form
of tracing if they need to see more context.

John
 
D

DJ Majestik

Exactly John!

In PHP, I roll up the global variables (serialized) and write that out
to a log file with a reference number. Then if I need to see the
details, I can just unserialize and see the state the user was in right
before the error happened.

Since Java doesn't have globals, there is no easy way of doing this I
guess.

JJ
 
R

Remon van Vliet

Your problem is simply a lack of information, it's quite rare to figure out
what's going wrong from a single out-of-context stacktrace. Connect a
debugger to the application, or, if that's not possible, let the application
developer print some additional output when exceptions are caught/thrown. So
it's not you not understanding, it's you not having enough information to
make any conclusions regarding problems that have arisen.

Remon van Vliet
 
D

DJ Majestik

Remon,

That is exactly my issue. I don't know how one would hook up a debugger
as it is just an email thrown to me, but we have no mechanism in place
to match the exception emailed to the system out logs on the server. It
would be nice to have some way of knowing exception #100 matches system
out log #100. That is probably something that I would have to put in
place in each script though, right?

Thanks,
JJ
 
J

John Currier

That's not exactly what I had in mind. I grabbed all of the automatic
variables on the stack and matched them to the debug information in the
executable, printing that out with the stack trace.

Your PHP example scares me in that it reminds me of old mainframe
programming techniques. You can have pseudo-globals in Java (known as
singletons), but I absolutely wouldn't want to use them to pass
parameters around.

Your code needs to be written in a manner that either optionally logs
information as it flows through your application or it logs the details
of the failures. I prefer to add context to the failing exception and
re-throw it.

John
 
T

Thomas Weidenfeller

DJ said:
The call-stack points out the location of the error (sometimes) but
doesn't show the state the user is in. I am then trying to guess what
the user did on the page to cause the error.

What the user did? That is not particularly relevant. Well, yes, it is
to some extend, but I would tread such a problem at another level.

The fact is your method tries to dereference a non-existing object.
Independent of what the user did, this should never happen. Users do
"interesting" things all the time, user's browsers do very "interesting"
things all the time and non of these should have an influence on the
robustness of the application.

So the problem at hand which needs to get fixed is that you have a
method which is not robust. You need to find the method or methods in
the call stack which happily handled, created, forwarded the null
reference, but shouldn't.

This might be the method where the NPE happened, or another method in
the call stack. The exact one depends on the design of your application.
Which one shouldn't have worked with the null reference going unnoticed?
Where should the NPE have been detected first? This is/are a method(s)
which needs fixing. How? Again, this depends on the design of your
application. You could add a test and return a graceful error message.
You could return some default result, instead of attempting to work with
the null reference. You could set the null reference to some default
value and continue processing. You could silently discard the user's
request, etc.

You can do a lot of things just with the stack trace and your source
code at hand. Read your source code. You have to know your code to make
a decision.

I was just wondering if
there was something so that I could see something like record_id=100
showing that the user viewed record id 100, vs. not having that and
trying to guess at which record caused the error.

You don't need that. The information that the user viewed some record
means that there is something wrong in your code dealing (reading,
displaying, changing, etc.) with (potentially corrupt) records. Look at
the stack trace to figure out where you didn't take the necessary
precautions to guard against that.

/Thomas
 
D

DJ Majestik

Obviously I don't understand how to "read" the call stack as
proficiently as I should, but I just thought there should be more
information to go on other than something that resembled the stack
trace. What was the user last doing? Is it related to a session time
out? Was the user trying to reference something they shouldn't?

The more information given to a programmer, the more they are going to
be successful at figuring out what is going on. My frustration is the
lack of information a stack trace gives, and that it doesn't spit out
any system out information. Although this is logged to a file on the
server, there is no easy way for me to match the specific error in the
stack trace to the system out to gather that information.

I might see a SQL error. I might see that the session user_id was null.
My point was that when trying to look at error messages simply using
the stack trace, and specifically when it is not your code to begin
with, it is difficult to "guess" at what the user was doing before the
error happened.

Anyway, I am very new at Java, so I don't understand the nuances of the
language yet. Thanks for helping me out.

JJ
 
C

Chris Head

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DJ Majestik wrote:
[snip]
The more information given to a programmer, the more they are going to
be successful at figuring out what is going on. My frustration is the
lack of information a stack trace gives, and that it doesn't spit out
any system out information. Although this is logged to a file on the
server, there is no easy way for me to match the specific error in the
stack trace to the system out to gather that information.
[snip]

Hi,
I guess a way you might try doing this is to use a Logger instead of
System.out on the server, and then to explicitly catch all Exceptions in
the client at the top level and reprint them with a timestamp. Then you
can match the timestamp up (at least to within a couple of minutes) with
the Logger messages coming from the server. The Logger automatically
adds a timestamp to every message it produces.

It's not perfect, but it'll certainly narrow things down a bit. Of
course, this also requires that you have access to the source of the
entire system to replace all the System.outs with Logger calls, but
that's neither here nor there - it's just a suggestion.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFCsGy4gxSrXuMbw1YRAqKgAKDd4s5V/wdpq38VXJ8paDGsUS9kRgCfRFh0
OKk5r8308nuXSzhDzTovp3Y=
=B8xb
-----END PGP SIGNATURE-----
 
J

John Currier

It's not perfect, but it'll certainly narrow things down a bit.

It'll narrow things down, but not by much if you've got several
thousand concurrent requests on your server/in your logs.

John
 
J

John Currier

You can usually look at the line that caused the NullPointerException
and figure out what was null. Normally many of the candidates will
have been referenced prior to the failing line and can therefore be
removed as a candidate. Ideally you'll end up with a single plausible
culprit.

John
http://schemaspy.sourceforge.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top