eric liu wrote:
> Probably you are right. Right now my problem goes to NullPointerException, a
> most notorious problem in servlet programming for me. Simply put, the
> getParameterValues() can't get
> the parameter from the form generated by the same servlet file.
> When I push the next button, the servlet is called and is supposed to
> get and update parameter "rowid", but it doesn't. In the JWS console,
> I found the message of NullPointerException.
> Why? The NullPointerException happens so often I almost doubt that the
> HttpServletRequest is null. Anybody got the same exception when run Java
> Webserver, tell me how to deal with it? Thank you very much.
>
I'm going to be blunt and brutally honest here ... throwing a
NullPointerException (NPE) means that your application -- servlet or not does
not matter -- is broken. No ifs, ands, or buts allowed. (And I'm talking to
myself here too -- an application that I wrote is currently in beta test, and
we're still tracking down some intermittent NPE problems with it.)
>From my experience, the most common cause of NPEs is when you assume that a
particular method is going to return a non-null value, and it doesn't.
Sometimes, this is due to unclear or ambiguous documentation on the methods you
are calling. Most of the time, though, it seems to be because servlet authors
are not paying attention to the documentation that says "null" is a valid
return value in certain circumstances.
As an example, can the following statement return a null reference?
String value = request.getParameter("abc");
You bet it can -- if the client calls you without specifying a value for the
"abc" parameter, you are going to get back a null value. Then, if you try to
do something like this:
if (value.equals("xyz")) {
; // Do something
}
you have just triggered an NPE -- and it's your fault, because you didn't check
for this condition first. A test that won't throw an NPE for this might look
something like this:
if ((value != null) && value.equals("xyz")) {
; // Do something
}
Why does this work? Because of the way the Java language defines expression
evaluation in IF statements (it's the same in C and C++, by the way) -- if
value is currently null, the second part of the conditional is never evaluated,
so it won't throw the exception.
"But wait!", you exclaim. My servlet is *never* called without a value for
parameter "abc"! My question to you is, "what makes you so sure?". Do you
have any control over whether the user bookmarks the URL of your submitted-to
servlet, without any parameters? Do you have any control over whether the user
writes a proxy application of his/her own that requests your response, and
forgets to (or doesn't know it's required) set a value for this parameter?
Bottom line -- if your servlet throws an NPE because of this, it's *your*
fault, not the user's.
Sometimes, it is not quite so obvious why an NPE happens. Consider the
following code, which wants to create the upper case version of a particular
parameter's input value:
String valueUpper = request.getParameter("abc").toUpperCase();
Chaining method calls like this is tremendously useful -- but if the parameter
is not present, guess what ... you just triggered an NPE! You need to check
for this condition first.
>
> My file is too long to paste here. But any suggestion from your own
> experience is always helpful. Eric
> >Eric --
>
My advice is based on more years experience with this programming stuff than I
want to admit to (does anyone here remember teletypes, punched paper tape, and
110 baud modems??? :-):
* Always always always check the API documentation for methods
you call. Well-documented methods will tell you when "null" is a
valid return value, and when it is not. When it is valid, always
code defensively, checking for a null value, to avoid NPEs.
* Be paranoid about the values you get back from method calls,
and check for null values even when it "can't happen", unless you
know for a fact that null will never be returned.
* If your servlet throws an NPE, the first thing to do is run it
without a JIT, and with debugging output enabled, so that your
stack trace shows you the line number where the problem occurred.
Then, work backwards to see where you made an assumption that
something cannot be null, but it really was. Use an interactive
debugger, and/or lots of System.out.println() statements, to isolate this.
* If the problem turns out to be a method call that returns null when it
should not, go complain to the author of that method. But in the
mean time, put in "paranoia" checks as described above. (The user
sees YOUR servlet fail -- they don't see the underlying code you
are relying on!)
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
