Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2005

Tip: Looking for answers? Try searching our database.

Puzzled over NullPointerException

Thread view: 
ohaya - 21 Oct 2005 12:52 GMT
Hi,

I originally had some code (for doing an LDAP search using ldapjdk.jar)
that looked something like:

while (results.hasMoreElements())
    {
    LDAPEntry findEntry = null;
    try
        {
        findEntry = results.next();
        LDAPAttribute attribute = findEntry.getAttribute("cn");
        Enumeration enumValues = attribute.getStringValues();
        String commonName = (String)enumValues.nextElement();
        System.out.println("Common name: " + commonName);
        }
        catch (LDAPReferralException e)
        .
        .

The above code seemed to work ok, but then I wanted to have access to
the commonName outside of the try (for some println's, etc.), so I
changed it to:

String commonName = "";
.
.
while (results.hasMoreElements())
    {
    LDAPEntry findEntry = null;
    try
        {
        findEntry = results.next();
        LDAPAttribute attribute = findEntry.getAttribute("cn");
        Enumeration enumValues = attribute.getStringValues();
        commonName = (String)enumValues.nextElement();
        System.out.println("Common name: " + commonName);
        }
        catch (LDAPReferralException e)
        .
        .
       
But, when I did that, I started getting a NullExceptionPointer error, I
believe on the line where commonName was being assigned.

Can anyone explain why?

I eventually was able to get this working by changing commonName to a
StringBuffer, but I'm still puzzled by the problem, especially since the
nextElement() method seems to only throw a NoSuchElement (and not a
NullPointerException :(...

Thanks,
Jim
Roedy Green - 21 Oct 2005 13:36 GMT
>But, when I did that, I started getting a NullExceptionPointer error, I
>believe on the line where commonName was being assigned.
>
>Can anyone explain why?

see
http://mindprod.com/jgloss/runerrormessages.html#NULLPOINTEREXCEPTION

Whenever you ask for help about an exception on a newsgroup make sure
you  include the following:

The complete error message and complete stack trace.

The source code for at least the lowest level class you wrote
mentioned in the stack trace  with the relevant lines in the stack
trace marked in the source listing.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Roedy Green - 21 Oct 2005 13:40 GMT
>findEntry = results.next();
>        LDAPAttribute attribute = findEntry.getAttribute("cn");
>        Enumeration enumValues = attribute.getStringValues();
>        commonName = (String)enumValues.nextElement();
>        System.out.println("Common name: " + commonName);

presumably any of this code might fail returning null, and you do
nothing about it:

e.g.
>        LDAPAttribute attribute = findEntry.getAttribute("cn");
could be null
>        Enumeration enumValues = attribute.getStringValues();
could be null
>        commonName = (String)enumValues.nextElement();
could be null

you should code defensively to handle the null case. The line number
in your stack trace will tell you exactly there the problem is.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

ohaya@cox.net - 21 Oct 2005 16:46 GMT
> >findEntry = results.next();
> >        LDAPAttribute attribute = findEntry.getAttribute("cn");
[quoted text clipped - 15 lines]
> you should code defensively to handle the null case. The line number
> in your stack trace will tell you exactly there the problem is.

Roedy,

I forgot to mention that I had put in a bunch of printlns, to track
down which line was blowing up, and it was the "commonName =
(String)...." line.

If I'm understanding your post, you're implying that the nextElement()
might have returned a null instead of an object, which then caused the
NullPointerException.

I agree with that, but what's really puzzling me is why the
NullPointerException only occurs if I declare commonName inside the
try???

Thanks,
Jim
Roedy Green - 22 Oct 2005 00:43 GMT
>I forgot to mention that I had put in a bunch of printlns, to track
>down which line was blowing up, and it was the "commonName =
>(String)...." line.

that is a very good clue.

String commonName = (String)enumValues.nextElement();

could return null unless you did a enumValues.hasMoreElements() first
that returned true.

Hint: why would code work outside a (try) block but fail inside?

The most common source of that problem is:

Did you redeclare any variables?  The variable inside the block is not
the same as the variable outside.

You did not quote enough code to see if that applies.

I need to see your whole class and also the exact code you used
without the try.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

ohaya - 22 Oct 2005 02:27 GMT
> >I forgot to mention that I had put in a bunch of printlns, to track
> >down which line was blowing up, and it was the "commonName =
[quoted text clipped - 18 lines]
> I need to see your whole class and also the exact code you used
> without the try.

Roedy,

Try as I might (I've been spending more time on it tonight... a bit
embarrased because of my inability to create the problem again), I
haven't been able to reproduce the code and problem.

But, just to answer your question, no variables were redeclared inside
the try, and (really) sorry about not having posted enough code in the
first place.

Jim
Oliver Wong - 21 Oct 2005 17:03 GMT
> Hi,
>
[quoted text clipped - 42 lines]
>
> Can anyone explain why?

   I'm not familiar with Java's LDAP API, but I think the answer to your
question depends critically on the code that you did NOT post. Specifically,
on the code inside the catch clause. I recommend you construct and SSCCE and
post it. (http://www.physci.org/codes/sscce.jsp)

   Given that you're using the LDAP API, I'm thinking a lot of people won't
actually bother to run your code as they might not have easy access to an
LDAP service. However, if you can replicate the problem in a small snippet
about one page long, then you avoid the risk of leaving out code that might
be important for answering the question.

   - Oliver
ohaya - 21 Oct 2005 19:58 GMT
>     I'm not familiar with Java's LDAP API, but I think the answer to your
> question depends critically on the code that you did NOT post. Specifically,
[quoted text clipped - 6 lines]
> about one page long, then you avoid the risk of leaving out code that might
> be important for answering the question.

Oliver,

I've modified the original code (that had the problem) by now, and,
unfortunately, I didn't keep an exact copy of the code when the
exception was occurring.

I've been trying to undo the changes that I think I've made since then,
but now, I can't seem to make the problem happen :(...

I guess I'll have to live with the code that I have now, which is
working...

Thanks,
Jim
Ross Bamford - 21 Oct 2005 20:55 GMT
> I've been trying to undo the changes that I think I've made since then,
> but now, I can't seem to make the problem happen :(...
>
> I guess I'll have to live with the code that I have now, which is
> working...

IMHO that is one of the most dangerous attitudes in software development -  
"It just fixed itself so I left it".

(that's not a dig at you, OP, just a general observation).

Signature

Ross Bamford - rosco@roscopeco.remove.co.uk

ohaya - 21 Oct 2005 21:43 GMT
> > I've been trying to undo the changes that I think I've made since then,
> > but now, I can't seem to make the problem happen :(...
[quoted text clipped - 6 lines]
>
> (that's not a dig at you, OP, just a general observation).

Ross,

I agree, and I was a little worried that that might be the reaction to
my post.  

To be clear, I have working code now, including changes that I put in
specifically to eliminate the problem, and which seem to work, and in
the newer code, I've added additional checks for nulls, etc., as someone
else suggested earlier.

I spent about half a day today so far, trying to get my code back to
where the problem was occurring, to try to reproduce the problem,
because it seemed like a strange problem, but failed in that.  

I'm not saying that the problem fixed itself... it's more like I can
make my now-working code replicate the problem.

I guess that if I had not been so anxious to get things working, I
might've taken a snapshot, but I generally only do snapshots when I'm at
a point that I have working code :(...

Jim
Ross Bamford - 22 Oct 2005 00:42 GMT
>> > I've been trying to undo the changes that I think I've made since  
>> then,
[quoted text clipped - 22 lines]
> might've taken a snapshot, but I generally only do snapshots when I'm at
> a point that I have working code :(...

:) And who needs a broken snapshot anyway ...

You don't expect to have to roll back to the problem I guess, so why would  
you ? As I say it was just a reactionary observation, brought on by the  
memory of a million (or not, probably) tiny bugs that 'went away', only to  
return when least expected or desired.

And that's just in stuff I wrote ;)

(Aside: If you use Eclipse, you might find the 'Local History' feature  
useful - RMB -> Compare with -> Local History. Other IDEs now have similar  
features. I was pleasantly surprised by it recently myself.)

Signature

Ross Bamford - rosco@roscopeco.remove.co.uk

ohaya - 22 Oct 2005 02:32 GMT
> > Ross,
> >
[quoted text clipped - 22 lines]
> useful - RMB -> Compare with -> Local History. Other IDEs now have similar
> features. I was pleasantly surprised by it recently myself.)

Ross,

I appreciated the restraint in your earlier post.  My apologies that I
didn't acknowledge it...

I do use Eclipse on occasion, but mainly for larger projects.  That's
possibly another "lesson learned" (for me).

Thanks,
Jim
Roedy Green - 22 Oct 2005 03:11 GMT
>> You don't expect to have to roll back to the problem I guess, so why would
>> you ? As I say it was just a reactionary observation, brought on by the
>> memory of a million (or not, probably) tiny bugs that 'went away', only to
>> return when least expected or desired.

If you were a cat, a bug is a bit like a mouse that makes an
appearance only every week or so.  You have to take full advantage of
every observation.

For code of any complexity I like to just watch it run in a debugger
for a goodly while and make sure everything that happens is what I
expect. 95% of the time strangenesses are actually ok. Surprises are
easier to spot than bug droppings.

Of course writing a test harness to thoroughly exercise any class is
your best insurance, but it won't catch everything, e.g duplicate
actions.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Ross Bamford - 22 Oct 2005 03:46 GMT
>>> You don't expect to have to roll back to the problem I guess, so why  
>>> would
[quoted text clipped - 6 lines]
> appearance only every week or so.  You have to take full advantage of
> every observation.

Nicely put :)

> For code of any complexity I like to just watch it run in a debugger
> for a goodly while and make sure everything that happens is what I
> expect. 95% of the time strangenesses are actually ok. Surprises are
> easier to spot than bug droppings.

I'm not sure about that 95% of the time, but even were it true you'd want  
to make sure you were actually in that 95%. Debugging / profiling is a  
necessity in modern systems - sad but true. The average Java is so far  
removed from the machine, and usually with parts from many sources, that  
you just can't hold it all to account otherwise. For example, I can't  
remember the last time I did anything bitwise If my experience has taught  
me anything, it's that computers aren't supposed to surprise me.

> Of course writing a test harness to thoroughly exercise any class is
> your best insurance, but it won't catch everything, e.g duplicate
> actions.

I love it when you see a project that's obviously been written test-first,  
and they've got clover on there, and made it a roadmap target to "reach  
100% coverage" - like it's a deliverable. So you look through the pretty  
(enormous) clover reports and sure enough, every statement has been  
executed (apart from those few they excluded at the last minute), and all  
the bars are green. Every class _works_, as demonstrated by the fact that  
each and every method has been called with a carefully contrived set of  
arguments by another method. Sometimes several times.

Of course, any newbie can write a class to spec - it's Java 101. Writing  
classes that work, _together_, in the wild, well... that's just not what's  
driving the design.

How many products / projects have you seen that didn't work, or didn't  
perform, purely because no-one had checked the impact of everything  
working _at the same time_ during development?

Signature

Ross Bamford - rosco@roscopeco.remove.co.uk

Roedy Green - 22 Oct 2005 00:46 GMT
>I spent about half a day today so far, trying to get my code back to
>where the problem was occurring, to try to reproduce the problem,
>because it seemed like a strange problem, but failed in that.

what you can do in such a situation is create an inprogress directory
on your disk and copy your work there every once in a while. That lets
you back up or trace changes in a very low tech way.

For a more format system, you can use a local CVS or Subversion
server, and you check your code in periodically. That way you can back
up, or create various branches for your experiments.

see http://mindprod.com/jgloss/cvs.html
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.



Free Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
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



©2009 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.