java vector nullpointerexception

Joined
Apr 4, 2003
Messages
836
Code:
import java.util.*;
import java.lang.*;

public class queue{


  
  private Vector<Integer> victor;
  
  void queue(){
  	victor=new Vector<Integer>();
  }
  
  void enqueue(int vertex){
  	Integer temp = new Integer(vertex);
  	victor.addElement(temp);//CRASHES RIGHT HERE
  }
  
  int dequeue(){
     if(victor.isEmpty())
        return -1;
        
     return ((Integer)victor.remove(0)).intValue();

  }
}

what causes enqueue to crash with a NullPointerException the very first time it is called?
 
ahh, dammit.

i didn't even need to read the link once you said the problem was in the constructor. i have no idea why i told that thing to return anything.

yes, it was a homework assignment... but not like what you're thinking.

this class was only one small part of a larger project on graph algorithms... i had the whole thing working when i was using an array as the queue inside that class rather than a vector... but i decided to try something new for a change and use a vector.

of course i remembered to return nothing in the constructor, then...

thanks

edit: kind of makes me wish compilers would give warnings: hey! you didn't write a constructor, so i'm using my own!
 
nameless_centurian said:
ahh, dammit.

i didn't even need to read the link once you said the problem was in the constructor. i have no idea why i told that thing to return anything.

yes, it was a homework assignment... but not like what you're thinking.

this class was only one small part of a larger project on graph algorithms... i had the whole thing working when i was using an array as the queue inside that class rather than a vector... but i decided to try something new for a change and use a vector.

of course i remembered to return nothing in the constructor, then...

thanks

edit: kind of makes me wish compilers would give warnings: hey! you didn't write a constructor, so i'm using my own!

Just a couple of tips...if you are doing any sort of Java development...some good habits to have:

1.) Use CamelCase (http://en.wikipedia.org/wiki/CamelCase). This means your class would be named "Queue", your methods would start with lower case letters. Then you could see the constructor easily (or the lack of one).

2.) Use a good IDE. I can't say this enough. Download Eclipse and use it. It will change your life.

3.) Know the API. In your specific example, why are you using a Vector? Did you know that there is an equivalent class called ArrayList? Do you know the difference?

4.) Familiarize yourself with all the features of the language.

It appears you are using Java 1.5 since you are genericising your Vector object. Did you know that Java 1.5 will also do auto-boxing and unboxing of primitive types when you add them to genericised classes? See this link for more information:

http://java.sun.com/developer/technicalArticles/releases/j2se15/#ease and scroll down to "Autoboxing and Auto-Unboxing of Primitive Types".

Developing good habits is easy if you start early...
 
generelz said:
Just a couple of tips...if you are doing any sort of Java development...some good habits to have:

1.) Use CamelCase (http://en.wikipedia.org/wiki/CamelCase). This means your class would be named "Queue", your methods would start with lower case letters. Then you could see the constructor easily (or the lack of one).

i'll definitely start doing so. thanks.
2.) Use a good IDE. I can't say this enough. Download Eclipse and use it. It will change your life.

does Vi count? ;)
3.) Know the API. In your specific example, why are you using a Vector? Did you know that there is an equivalent class called ArrayList? Do you know the difference?

i knew no such thing! i'll examine it, thanks
4.) Familiarize yourself with all the features of the language.

It appears you are using Java 1.5 since you are genericising your Vector object. Did you know that Java 1.5 will also do auto-boxing and unboxing of primitive types when you add them to genericised classes? See this link for more information:

http://java.sun.com/developer/technicalArticles/releases/j2se15/#ease and scroll down to "Autoboxing and Auto-Unboxing of Primitive Types".

Developing good habits is easy if you start early...

i assume by "boxing" and "unboxing" you mean there is no need to use a wrapper class for primitives? [edit] just read the link, thanks. [/edit]

and i don't think i am understanding how i am genericising the vector because i declared it and told it to hold objects of type Integer

could you explain, please?
 
nameless_centurian said:
i'll definitely start doing so. thanks.

You're welcome.

nameless_centurian said:
does Vi count? ;)

Even though it was what I used to program Java in college I wish I had been able to use Eclipse now. Even if it means you have to write your stuff locally and then SFTP it to the turn-in machine to test compile, etc. I think it is worth it. Of course, just make sure that your local machine is running the same JVM as the remote machine (the machine that your professor/TA will be testing/running your code on).

nameless_centurian said:
i knew no such thing! i'll examine it, thanks

In short for 95% of cases you will want to use ArrayList. Vector is a synchronized implementation of List which adds overhead. Synchronization is only relevant if you are writing a threaded application where the List is shared across multiple threads (multiple threads adding/removing items at any point). If you are not using it in this manner ArrayList will be faster for you.

nameless_centurian said:
i assume by "boxing" and "unboxing" you mean there is no need to use a wrapper class for primitives? [edit] just read the link, thanks. [/edit]

Yeah, exactly. No need for:

Code:
Integer temp = new Integer(value);

or

Code:
 int foo = ((Integer)victor.get(i)).intValue();

nameless_centurian said:
and i don't think i am understanding how i am genericising the vector because i declared it and told it to hold objects of type Integer

could you explain, please?

Sure. What I mean by genericising a class is when you use the angle brackets "<SomeClass>" after the class declaration. What this tells the compiler is "this class will only hold/deal with this type of object". In the case of Lists/Collections this means that when you call "add()", the compiler is able to check the type of the object you are adding and give you an error if you're trying to add something that doesn't match. Additionally when you call "get()" it will return an item of that type so you don't have to cast it.

Of course, this only helps if you are using homogeneous Lists. There are all sorts of wildcards and such that you could put in the angle brackets to support semi-heterogeneous lists but that is probably beyond the scope of what you need to know (or what I want to explain).

Let me know if that helps or if you have any more questions...
 
Some more free advice: learn to use your debugger. If this had happened to me, I'd see the crash, put a breakpoint before the crash and run again and discover the null number. But since I knew the constructor should've initialized it, I'd put a breakpoint there. When I found that the constructor breakpoint wasn't hit, I'd have my answer.
 
mikeblas said:
Some more free advice: learn to use your debugger. If this had happened to me, I'd see the crash, put a breakpoint before the crash and run again and discover the null number. But since I knew the constructor should've initialized it, I'd put a breakpoint there. When I found that the constructor breakpoint wasn't hit, I'd have my answer.

Yeah, totally neglected to mention that. Having a debugger and learning how to use it is one of the best if not the best tool/skill a programmer could have. Going along with the "use an IDE" point I mentioned above most Java IDEs have a debugger built in, something you won't get with vi :p .
 
mikeblas said:
Some more free advice: learn to use your debugger. If this had happened to me, I'd see the crash, put a breakpoint before the crash and run again and discover the null number. But since I knew the constructor should've initialized it, I'd put a breakpoint there. When I found that the constructor breakpoint wasn't hit, I'd have my answer.

guilty as charged. i should have used a debugger.

i guess i got a little arrogant and thought: "this has to be some crazy rule i don't know about because i can see plain as day that this should be working."


thanks, everybody.
 
Debugging is an art. And generelz is right about its importance: when interview people, I ask debugging questions and won't hire guys who start blaming their tools ("The Whamco compiler sucks! I'd rather use the Bitmore compiler."), bitching about technologies ("This wouldn't happen in Java. We should rewrite it in C++."), bitching about the code ("You should rewrite it anyway to use {some cool feature here}"), and so on.

In my experience, I've noted that checking things that "should be" or "really must have" really are. If they're obvious, they should be blindingly simple to verify. Good code will include assertions to verify them on the fly, in fact.

"Why isn't my constructor called?" sounds like a much better question than "I can't understand this crash".
 
Back
Top