Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Error from sudoku class

 
Nattakan Lukkanapinit
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is my code about SUDOKU
I got this error and don't know what it is.





 
Greg Charles
Sheriff
Posts: 2985
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you initialize the suds array:

SudCell suds[][] = new SudCell[NUM_VALS][NUM_VALS];

that creates a two-dimensional array of nulls. That's an important point to remember with Java. When you try to work with one of those values, you instantly get a NullPointerException. You need to instantiate each element of the array using "new SudCell()" before you reference it.
 
Nattakan Lukkanapinit
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why i can't just call like this



 
Campbell Ritchie
Sheriff
Pie
Posts: 48972
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never use == true or == false. Use if (xxx) or if (!xxx)
 
Rob Spoor
Sheriff
Pie
Posts: 20532
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hong hong wrote:Why i can't just call like this


Because that calls suds[x][y].SetToBlank(); for each array element, but these are still all null as Greg said. In your constructor you need to add a block to initialize the array elements: suds[x][y] = new SudCell();
 
pete stein
Bartender
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
cross-post: java-forums thread
 
Rob Spoor
Sheriff
Pie
Posts: 20532
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hong hong, please BeForthrightWhenCrosspostingToOtherSites.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A few comments:

Java naming conventions: Standard Java naming conventions include starting method and variable names with a lower-case letter. Doing otherwise makes code more difficult to read than necessary.

Simplify logic expressions:Code organization: Put separate classes in separate files. To do otherwise obfuscates the logical separation of functionality, and makes navigation more difficult than necessary on both editing and cognitive levels.

Simplify flow: Consider your boolean RuleOut(int) method: first, every single path returns false. You only need one return, outside of any conditional. Second, pay attention to what you're doing: do you see any relationship between the val being passed in and the array index you're setting? This is a two-line method, unless the logic is completely wrong--which is possible, because a boolean method that always returns false doesn't need to return *anything*.

Particularly when trying to get help from people it's really important to keep things as simple, clear, and concise as possible. For your *own* benefit as well--code that's easy to read is easier to debug, understand, explain, extend, etc.
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're going to get a lot more errors--you're trying to test things that are going to throw runtime exceptions.

Right now it seems to me like you wrote everything at once without running *anything* -- the main method isn't going to get passed the forcedSet(-1) line before crashing.

Start small. Test as you go. Look for ways to simplify what you're doing--don't just blindly throw code at a problem without taking the time to reflect on what you've just written. Be consistent in conventions. Localize functionality. Make sure you're not doing more work than necessary; simple example:Here you're both not being consistent and doing more work than necessary--if the valuePresent(1) call is going to print correctly, why bother with the Boolean.toString(...) wrapping of the others? (And consider printf :)

I'm finding the code very difficult to follow as I bang on it, it's not clear to me what the intent of many things are. These things are fixable without a huge amount of effort.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic