On Thu, 26 Aug 1999, Craig R. McClanahan wrote:
[ ... ]
> 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.)
[ ... ]
> 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!)
Yeah, what he said!!!
As another example, I just had to track down a NPE in my application.
Turns out it was due to a condition in a database file that wasn't
supposed to happen. Now this database file is one my code creates,
and so since I have complete control over it, I just knew that
condition wouldn't happen :-). I fixed the problem in the code that
created it, so now it won't happen again. And I've changed the other
code so that it behaves nicely should something similar happen again
(e.g. don't just assume the condition won't happen, check for it, fail
gracefully, and report "invalid condition in database"). This is
probably something I should've done in the first place (defensive
programming and all). (Well, I had done it in some places, but not
everywhere.)
The point is that this can happen even when you have complete control
of the code, and defensive programming suggests you check for it
anyway.
On another semi-related now, I notice that there are a fair number of
posts on this list where someone just says that their code doesn't
work, or that they get such and such exception, perhaps showing the
stack trace, asking what the problem is, seemingly without doing any
debugging themselves. Debugging is a major part of programming (more
major for some than others :-), something that it's very important to
be able to do to produce good applications. It's also something that
the original programmer *should* have the best handle on, since they
know the code the best. People should make an effort to debug things
themselves before posting to the list.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]
___________________________________________________________________________
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
