 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2005Better Java error messages
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 > 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  SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq 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 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 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 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 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 > Can't connect a debugger to it, because these are emails with the stack > trace that come in. [quoted text clipped - 10 lines] > > JJ 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 > 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 SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq 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 [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 > 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 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.