aspose file tools*
The moose likes JDBC and the fly likes Nullpointer when retrieving values Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Nullpointer when retrieving values" Watch "Nullpointer when retrieving values" New topic
Author

Nullpointer when retrieving values

David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
My classmate and I are working on a distribution center inventory web app using JavaEE (not a graded assignment), and when I run my servlet the UI and everything loads fine, but when I hit the search button in the browser, we're getting a nullpointer at line 94 (result = stmt.executeQuery(query);) of his class. He's more experienced with MySQL, but is out of commission with appendicitis, so he can't really troubleshoot this with me. A lot of the solutions in other topics were already correct in his code so I'm not sure where to go with this. Total newb.

Here is my servlet:




And here is his class:



The nullpointer is happening at line 94 of his class, which if this formatted correctly, should be:



Everything looks good to me, and it may be something inside Tomcat that doesn't like his code, because before he went out of commission he said everything was working on his end in MySQL. Any ideas?


EDIT: Here's the top of the stack trace if this helps:

Jun 20, 2014 1:45:47 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [com.edu.search.Search] in context with path [/Search] threw exception
java.lang.NullPointerException
at com.edu.search.PDB.pDBQuery(PDB.java:94)
at com.edu.search.Search.doPost(Search.java:90)
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61424
    
  67

Why is everything static?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Bear Bibeault wrote:Why is everything static?


Hah, good question! Most of that is what my classmate wrote, and he's kind of incapacitated so I can't ask him
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

David Borchgrevink wrote:we're getting a nullpointer at line 94 (result = stmt.executeQuery(query);) of his class.


Then that means the "stmt" variable is null.

Which would be because it's never assigned a value. Which would in turn be because the line of code before its assignment ("DriverManager.getConnection...") threw an exception. Which you should be able to find about because those exceptions are logged somewhere.
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:
David Borchgrevink wrote:we're getting a nullpointer at line 94 (result = stmt.executeQuery(query);) of his class.


Then that means the "stmt" variable is null.

Which would be because it's never assigned a value. Which would in turn be because the line of code before its assignment ("DriverManager.getConnection...") threw an exception. Which you should be able to find about because those exceptions are logged somewhere.


Thanks for the response! Yea I got that part about "stmt" being the cause, but I missed that it's actually the DriverManager.getConnection line throwing the exception. Good suggestion on looking through logs. Again very new at this. Thanks!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

Really that catch-block in the PDB class should be throwing a RuntimeException after logging the SQLException; as it's written it basically ignores the SQLException and allows processing to go on until something else fails. You noticed already how hard it is to track down the reason for the secondary failure, right?
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:Really that catch-block in the PDB class should be throwing a RuntimeException after logging the SQLException; as it's written it basically ignores the SQLException and allows processing to go on until something else fails. You noticed already how hard it is to track down the reason for the secondary failure, right?


No, I don't think I have. After seeing your first response I've been doing some googling on what I can do to remedy the DriverManager issue :/
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

The primary problem was that the driver didn't load. The secondary problem was that you had a NPE elsewhere. It wasn't obvious to you that the secondary problem was because the primary problem had been ignored.
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:The primary problem was that the driver didn't load. The secondary problem was that you had a NPE elsewhere. It wasn't obvious to you that the secondary problem was because the primary problem had been ignored.


Yea and it's been giving me hell, that driver. I believe I have it placed in the right places. I read somewhere that it also needs to be added to the CLASS_PATH is that right? Just to be sure can you tell me exactly where that .jar needs to be? I thought I had that issue fixed because I was originally getting an error specifically regarding that driver, but I wasn't seeing that the last couple times I've tried running... ugh...


EDIT: whoops just checked again, and of course, still getting that no suitable driver error.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

Classpath? Yes... but you posted some code for a servlet, so am I right in assuming that you're running this in some servlet environment like Tomcat? If so then the driver jar should go in the web application's WEB-INF/lib folder.
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:Classpath? Yes... but you posted some code for a servlet, so am I right in assuming that you're running this in some servlet environment like Tomcat? If so then the driver jar should go in the web application's WEB-INF/lib folder.


You are correct sir. Unfortunately I already have the jar in the WEB-INF/lib folder as well :/ One thing I'm seeing while googling this is the registering of the driver using

I'm going to try putting that in the code, because it's the one thing I'm not seeing in my classmates PDB class
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

You don't need the Class.forName line if two conditions apply: (1) you're using Java 6, and (2) the driver is JDBC 4.0 compatible. You should certainly be using Java 6 by now, and the latest version of the driver should certainly support JDBC 4.0, but anyway you should really ensure that both of those conditions do apply.
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:You don't need the Class.forName line if two conditions apply: (1) you're using Java 6, and (2) the driver is JDBC 4.0 compatible. You should certainly be using Java 6 by now, and the latest version of the driver should certainly support JDBC 4.0, but anyway you should really ensure that both of those conditions do apply.


hey thanks again for the reply. Yea I saw and read both of those things a bunch, but many people were saying even past Java 5 that even though it's legacy code, that it's still needed. me? I don't know what's right either way. now as for the driver being jdbc 4.0 compatible, I'm not sure of, but I would assume it is since it's the most recent connector .jar

either way, I did try adding that line in, and poof, I get no errors in eclipse when I click that search button in the browser, BUT, I just get a blank white page. it was very refreshing to see honestly, but now I have to figure out if that's good or bad progress because hitting the search button with all empty fields should act as a wildcard and show all items in the product table of the database. either way, I got really burned out yesterday, so I may wait a little bit before I try and hammer back at this again today
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18657
    
    8

Here's my opinion: you've got a whole lot of code and it's all untested. And servlets are a really poor testing environment. So why don't you back up a bit -- write a command-line program which tests your database access, to get that working first. Then you can put the working code into the servlet.
David Borchgrevink
Ranch Hand

Joined: Feb 08, 2014
Posts: 91
    
    1
Paul Clapham wrote:Here's my opinion: you've got a whole lot of code and it's all untested. And servlets are a really poor testing environment. So why don't you back up a bit -- write a command-line program which tests your database access, to get that working first. Then you can put the working code into the servlet.


awesome advice! and by no coincidence, that is exactly what i did last night before i checked out. The database was connecting everything was working. and like you suggest, i then added in my classmates code and boom the exact same nullpointer. i think really, i might need to wait til my buddy is recovered so we can go through his code together, because it's still somewhat foreign to me. but at least i know my test code connected to his database just fine :)

great minds think alike :D
 
Consider Paul's rocket mass heater.
 
subject: Nullpointer when retrieving values