Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Array: NullPointerException  RSS feed

 
Matthean Brown
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Error comes up when I try to add a contact via the ContactBook.add() function.





 
Paweł Baczyński
Bartender
Posts: 2054
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You never create an instance of Contact inside add() method.
Because entries[entries.length - 1] is null you see NullPointerException.

Some points:
Why are you copying the array every time you try to add a contact? You should use a List.
Why should a ContactBook care about scanners and reading input? It should only care about adding/removing/updating/retrieving contacts.
 
Matthean Brown
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I fixed the error. The lack of List is due to this being for a class and us not supposing to know how to use one just yet. The scanner being past is part of the requirement. I tried for the life of me to figure out why it was done that way based on the specs and the best I came up with was if it was an array, but I couldn't find a way to do it, so I just passed a scanner object. I'll ask for clarification once I know the rest is working.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16026
87
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthean Brown wrote:The scanner being past is part of the requirement.

Paweł Baczyński wrote:Why should a ContactBook care about scanners and reading input? It should only care about adding/removing/updating/retrieving contacts.

What Paweł was trying to make clear with his remark is not that you should not use Scanner, he was trying to point out an important principle of object oriented programming: separation of concerns.

A class (or on a smaller level, a method) should only have one responsibility. For example, the only thing an address book class should do is keep track of a list of addresses. It should not deal with other things that don't directly have to do with that, such as reading input from the keyboard. That should be in a separate class, that only deals with that specific task.

Why is this: Because it makes the structure of a program much better and much easier to understand. Imagine that you have a big program with lots of classes, and each of the classes does a whole list of different, unrelated things. It would be really hard to understand which class is responsible for which part of the functionality of the program, and it would therefore be very hard to maintain that program.

If your teacher or course designed class ContactBook in such a way... then you should take it as an example of how not to design a class.
 
Matthean Brown
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, I know. It was the reason why it took so long to figure out what I was suppose to be doing as it felt needless the way it was hinted at. If I knew how to store scanner data across multiple lines within the scanner itself, it would be more straightforward.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthean Brown wrote:Oh, I know. It was the reason why it took so long to figure out what I was suppose to be doing as it felt needless the way it was hinted at. If I knew how to store scanner data across multiple lines within the scanner itself, it would be more straightforward.

I doubt that. Apart from the fact that they duplicate a lot of code, your add() and update() methods in ContactBook look perfectly reasonable to me.

I would qualify Jesper's post with one addition though: A class should know how to create an instance of itself in whatever way necessary, so I have no particular problem with a constructor like:or indeed - and possibly even better - a static factory:although not everybody will agree with me about this.

What we do agree on is that the business of getting input from a Scanner does NOT belong in a Contact class; so if you do write a method like the one above, don't include stuff like s.nextInt() in it. You might find the UserInput page worth reading for some pointers on how to write generic user input methods (or indeed, a utility class).

I would also add one tip: Whenever you write a class, write one constructor that takes ALL the private fields it defines as parameters - ie, in your case:and make this the ONLY constructor you write to begin with. You may need to add other ones later, but don't do it until you know you need do.

HIH

Winston
 
Matthean Brown
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After a lot of hemming and hawing by the professor I finally got him to admit that I don't have to pass the data via a Scanner even though the spec says to.
 
Liutauras Vilda
Marshal
Posts: 4624
316
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I don't see someone mentioned that, but you should choose your variables a bit more carefully.
When you do have a method:
What does "p", "phone" represents? phone number? maybe phone model? If you still want to leave such a variable names, then method name should be more descriptive (better both). If such a questions comes to the mind when someone from outside looking at your code, it is a good indicator, that chosen variable names are not descriptive enough.

The same as method:
"a", "address" - home address, office address, company address, pick up point address?

It is rather important in order to have less questions when look at your code.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!