theunreplicated / coloradocollegegame

Automatically exported from code.google.com/p/coloradocollegegame
0 stars 0 forks source link

[resoloved] NullPointerException on keyboard input #9

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I can run the program as specified. It brings up a blank (white) Frame with
nothing in it. When I hit one of the arrows, I get a NullPointerException.
If there is something I'm doing wrong, then that should be specified in the
instructions.

Terminal output below:

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ java Server &
[1] 1784

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ java Client &
[2] 3344

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at World.nudgeElement(World.java:47)
        at ClientIO.moveSelf(ClientIO.java:66)
        at ClientIO.keyPressed(ClientIO.java:98)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown
Source)

        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown
Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown
Sour
ce)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)

        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

Original issue reported on code.google.com by joelwr...@gmail.com on 2 Feb 2007 at 3:28

GoogleCodeExporter commented 9 years ago
Hmm... interesting. Would you mind running both Client and Server in the 
foreground
rather than background? Benjamin and I had never tried them in background, 
though I'm
guessing that it shouldn't matter. Also, make sure that you're working on 
Mathserver,
unless you've changed the code to work elsewhere (see Issue 2). I think that 
you'd
get a different error if you were elsewhere, but I'm not sure.

Also, it would help if you ran both Client and Server in verbose mode so that we
could see what the code thinks that it's doing.

Thanks!

Original comment by Omer.Ba...@gmail.com on 2 Feb 2007 at 3:38

GoogleCodeExporter commented 9 years ago
I'm going to guess that it's because I'm not running on Mathserver (I assume, 
since I
didn't do anything to make it run on mathserver). If that is the case, then it 
should
do SOMETHING to tell the user that they're not connected or not running 
properly or
something. They shouldn't be able to get to a point where they're breaking 
because of
a NullPointer error.

I ran backgrounded so that I could run both from the same terminal (I was lazy 
and
didn't want to open another instance of cygwin)

Yup, that's it:

jross@IT-20F4Y21-0610 ~/coloradocollegegame
$ java Client -v
Connecting...
Failed to connect to server: Connection refused: connect

So I guess this is just an extension of Issue 2. You should have the 
application quit
if it fails to connect, rather that just print out an error if someone is 
running in
verbose mode (which isn't the default).

Should I delete this issue then and maybe post a comment in Issue 2? (I don't 
know
how this bugtracking works)

Original comment by joelwr...@gmail.com on 2 Feb 2007 at 5:21

GoogleCodeExporter commented 9 years ago
Hey, Joel! Sorry to take so long to get back to you...

I'll tell you what I think we should do:
a) Flag this issue as "resolved."
b) Create a new issue with the new problem (which I think is a pretty valid one)
that, on failing to connect to the server, the game should print something and 
then
die (rather than not printing anything and then trying to function).

As an aside: the solution might well be to throw an exit statement into the 
correct
place and then to make it so that the message function in the Logger class 
prints
errors regardless of whether it is set to verbose or not. (You'll notice that 
every
time we send a message through the Logger, we also send a boolean for whether 
or not
it is an error.) It would make a lot of sense to print errors, or to change the
message function to take an int instead of a boolean, and ints of -1 (say) are 
so
critical that the Logger prints them to the screen regardless, whereas everyday 
types
of errors (a message didn't get passed that should have) are important for 
testing
and to log, but not really important for the end-user to see.

Original comment by Omer.Ba...@gmail.com on 2 Feb 2007 at 9:57

GoogleCodeExporter commented 9 years ago
Marking issue as resolved (a far as I know how. Is there a way to actually 
change the
lables to say "resolved?" or just remove the issue?).

Reposting problem in the appropriate issue.

Original comment by joelwr...@gmail.com on 5 Feb 2007 at 3:22

GoogleCodeExporter commented 9 years ago

Original comment by joelwr...@gmail.com on 6 Feb 2007 at 9:20