On Mon, Aug 20, 2001 at 11:57:25AM +0100, Dave Denholm wrote:
"Phil Garcia" PhilippGarcia@Home.com writes:
Thanks Anders for all the comments and questions.
From: "Anders Kierulf" anders@smartgo.com
[..]
(2) Error messages
Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
Great idea! I suggested something similar, using error code numbers, but your suggestion is much better. I will add this to the GTP specification.
We could do what the existing internet protocols do (smtp, nntp, ...), and have both a 3-digit error code, followed by explanatory text.
(I haven't found the original proposal either, so I'm responding only to the comments.)
I think it's a good idea to have a mechanism for extensions which is smart enough to allow a standard "not implemented" response.
However, I'm not sure whether error messages need to be standardized. (I'm not considering "I don't have your [optional] extension" to be an error condition.) Protocols like SMTP and HTTP (dunno NNTP) which do the standard error condition thing have a need for nontrivial error recovery because they are used by long-running daemons (e.g. mailers talking to mailers, and proxies talking to proxies) without human operators present at either end, and they need to do smart things about long-term state (like queued mail messages and cached documents) in the presence of failures (like servers or network links going down). But in a Go protocol which is just used for tournaments, IGS-style client/server stuff, regression testing, and whizzy UIs, there might be no such need to make interesting error-recovery decisions without human input. Therefore, it might be sufficient always to handle errors by terminating the session and printing out or logging the error text.
In my experience, it can be very tedious to maintain software (and specifications for software) which does nontrivial error recovery based on error codes. Writing it the first time is OK, but when something changes, you end up with lots of work for large committees and then lots of annoying proof-reading and tweaking of every error-handling switch statement; or else the committee isn't gung-ho enough to keep up, and you end up with various ugly kludges because your error conditions evolve away from the standard. Using OO inheritance for error conditions helps reduce the pain at maintenance time, but it still takes a significant amount of space and work in the specification (as in e.g. Java and Common Lisp). If you could get away without any fancy error recovery at all, it might be a good thing.