Closed GoogleCodeExporter closed 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
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
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
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
Original comment by joelwr...@gmail.com
on 6 Feb 2007 at 9:20
Original issue reported on code.google.com by
joelwr...@gmail.com
on 2 Feb 2007 at 3:28