aspose file tools*
The moose likes Java in General and the fly likes Some ArrayList issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Some ArrayList issues" Watch "Some ArrayList issues" New topic
Author

Some ArrayList issues

Rachel Barnes
Greenhorn

Joined: Oct 28, 2012
Posts: 11
So the goal of this is to import a list of account numbers from a text file and then search for one that the user inputs and determine whether it's a valid account number or not. Here's the things that have got me stumped:

1) Line 40: Eclipse is saying 'found' cannot be resolved to a variable. Considering it's dealt with and that method is called before that line and the value returned, why is this showing up as an error?

2) Line 55: The error is reading "Dimensions expected after this token." If I switch 'int' to 'String,' it works, but since I'm only using a list containing integers, isn't that what I should be using?

Ishan Pandya
Ranch Hand

Joined: Feb 06, 2012
Posts: 223

Rachel Barnes wrote:So the goal of this is to import a list of account numbers from a text file and then search for one that the user inputs and determine whether it's a valid account number or not. Here's the things that have got me stumped:

1) Line 40: Eclipse is saying 'found' cannot be resolved to a variable. Considering it's dealt with and that method is called before that line and the value returned, why is this showing up as an error?

2) Line 55: The error is reading "Dimensions expected after this token." If I switch 'int' to 'String,' it works, but since I'm only using a list containing integers, isn't that what I should be using?



I dont think a generic type can be a primitive.. it should be ArrayList<Integer> instead of ArrayList<int>.. check that out.


OCPJP
Ishan Pandya
Ranch Hand

Joined: Feb 06, 2012
Posts: 223

boolean found is a local variable and you are using it out of its scope.. it is local to the method isValid().. check that out also.
Rachel Barnes
Greenhorn

Joined: Oct 28, 2012
Posts: 11
Okay. Fixed the two things that you guys mentioned. No errors are showing up whatsoever, but when I go to run it, I get:

"What account would you like to search for?
Exception in thread "main" java.lang.NullPointerException
at chargeAcctValidation.isValid(chargeAcctValidation.java:71)
at chargeAcctValidation.main(chargeAcctValidation.java:36)"

If these aren't marked as errors, why is it saying there is a problem with them?


Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

Rachel Barnes wrote:Okay. Fixed the two things that you guys mentioned. No errors are showing up whatsoever, but when I go to run it, I get:

"What account would you like to search for?
Exception in thread "main" java.lang.NullPointerException
at chargeAcctValidation.isValid(chargeAcctValidation.java:71)
at chargeAcctValidation.main(chargeAcctValidation.java:36)"

If these aren't marked as errors, why is it saying there is a problem with them?


There's a difference between compiler errors and runtime errors. The compiler can only go so far - making sure you don't use variables that don't exist, or call methods that don't exist in that class etc. But there are plenty of errors that can happen that it can't protect you from.

A NullPointerException happens when you try to use a null reference as if it was pointing to an actual object. Your line 71:
There you're calling the size() method of AccountList. That's not going to work unless that variable is referencing an actual object. So where does the variable come from? From the method parameter. And what value do you pass in to the method? Line 36:

So you're passing null in. That's the cause of the problem. The compiler can't tell when it looks at line 71 what the value of AccountList is going to be, it's only at run time that this gets determined.

The only place you create an ArrayList is on line 46. But that's in a separate class that you've called listofAccts. You need to understand what it means for an object to be in scope at a particular point.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Rachel Barnes wrote:If these aren't marked as errors, why is it saying there is a problem with them?


First this: Errors can happen at two different times - at compile time (that you see in your IDE) and at runtime. When you write and compile code the compiler can check for syntax, code access, and things like that - static things that can be seen or predicted before code runs. It can't tell what state things will be in when code runs, so there is another group of errors - the Run Time Error/Exception that only occur when you run code. These usually relate to the current state of data / objects as code executes.

So the problem you see is something that can only be visible at run time. The code isn't necessarily a problem, but the state of the objects is.

So to your problem.
Rachel Barnes wrote:Okay. Fixed the two things that you guys mentioned. No errors are showing up whatsoever, but when I go to run it, I get:

"What account would you like to search for?
Exception in thread "main" java.lang.NullPointerException
at chargeAcctValidation.isValid(chargeAcctValidation.java:71)
at chargeAcctValidation.main(chargeAcctValidation.java:36)"


Line 71 you do: AccountList.size(). AccountList is supposed to be an Object, and you call a method on it (size()). In your code there is no Object stored in the AccountList variable, because in line 36 you sent a null value into the method. Since you sent a null value (null meaning 'no object') then you try to use the value as if it were an object you get NullPointerException.

You need to pass an actual ArrayList into the method in order to call methods on it.

Steve
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Steve Luke wrote: . . . First this: Errors can happen at two different times - at compile time (that you see in your IDE) and at runtime. . . .
Of course, there are some runtime errors which don’t raise Exceptions. They simply produce the wrong result. Those are called logic errors. They are by far the most serious kind.
Rachel Barnes
Greenhorn

Joined: Oct 28, 2012
Posts: 11
Switched up some things and I think I've got it somewhat worked out. However, on Line 74, I am now getting "Incompatible operand types Object and Int." I took index out to see if it offered anything, and it suggested "Add argument to match get(int)" ....leading me back to inserting index, and then it says it's wrong again. Some examples I've looked up say to insert zero (which I also tried-- and which index is set to anyway), and it was the same. Is 'get' not what should be used there?


Rachel Barnes
Greenhorn

Joined: Oct 28, 2012
Posts: 11
Matthew Brown wrote:
Rachel Barnes wrote:Okay. Fixed the two things that you guys mentioned. No errors are showing up whatsoever, but when I go to run it, I get:

"What account would you like to search for?
Exception in thread "main" java.lang.NullPointerException
at chargeAcctValidation.isValid(chargeAcctValidation.java:71)
at chargeAcctValidation.main(chargeAcctValidation.java:36)"

If these aren't marked as errors, why is it saying there is a problem with them?


There's a difference between compiler errors and runtime errors. The compiler can only go so far - making sure you don't use variables that don't exist, or call methods that don't exist in that class etc. But there are plenty of errors that can happen that it can't protect you from.

A NullPointerException happens when you try to use a null reference as if it was pointing to an actual object. Your line 71:
There you're calling the size() method of AccountList. That's not going to work unless that variable is referencing an actual object. So where does the variable come from? From the method parameter. And what value do you pass in to the method? Line 36:

So you're passing null in. That's the cause of the problem. The compiler can't tell when it looks at line 71 what the value of AccountList is going to be, it's only at run time that this gets determined.

The only place you create an ArrayList is on line 46. But that's in a separate class that you've called listofAccts. You need to understand what it means for an object to be in scope at a particular point.


So should listofAccts not be its own class? Should it be put into main?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Rachel Barnes wrote:Switched up some things and I think I've got it somewhat worked out. . . .
What sort of switching technique did you use?

When people say that sort of thing, it sounds as if they are guessing. You can guess a million times, and there is a good chance one of those guesses will be near the right solution. Or you can work out your solution properly, which means pencil paper and eraser, away from your screen. When you have worked that out, it will be right first time.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Rachel Barnes wrote: . . . So should listofAccts not be its own class? Should it be put into main?
Why did you put it in its own class? Why did you write an inner class? Where are you using that list? Can you write a method to add to it? Or find a particular number in it? What good would it be in the main method? If you are calling the class xyzValidation, is that the whole app? How many main methods are you going to call in the whole app? Is that main method only there to test the validation?

When you have answered those questions, you will know where the list belongs
By the way, it is a good idea to put a main method into each class so you can execute that class and test it before inflicting it on the rest of your app.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

Rachel Barnes wrote:So should listofAccts not be its own class? Should it be put into main?

Whether it should be depends on what you're trying to do. But as things stand you aren't using that class anywhere - you could remove it completely and it would make no difference.

To reinforce what Campbell said, it does sound too much like you're just moving things around without understanding what they do. You shouldn't have a single line of code that you don't understand what it does, and why it's where it is. And if you do you need to take a step back and revisit the basics rather than just guessing.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8419
    
  23

Rachel Barnes wrote:Should it be put into main?

I agree completely with Campbell and Matthew; however, the general answer to the above question is 'NO'.

You normally want to be taking things out of main(), not putting them in. Indeed, most experienced programmers try to keep their main() methods as small as possible - often only one line.

HIH

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
 
 
subject: Some ArrayList issues