4 ms·

I'd be interested to see commentary on the error handling he decided on (basically: r = write(x, r) r = write(y, r) etc, with write being: func (x, ok): if

• xal 17y ago
  Yea that's probably an artifact of a C code. The correct way to handle this in go ( i think, i'm a beginner like everyone else ) is to pass around a request struct that contains an error channel and have the main connection handling gorutine select on this. That's at least for bigger picture errors. On the method level you should use multiple return values to indicate erros (usually as last return value). So r, err = write(y) { if (err!=nil) { request.errors <- err; return } }
  • dlsspy 17y ago
    The most important part is to stop doing the thing that isn't working. If I communicate this to the channel and the channel is read by the current goroutine, then the channel's buffer must be large enough to handle the total number of errors that may occur in a single invocation or the goroutine will deadlock on itself.
• dlsspy 17y ago
  I commented on that here: http://dustin.github.com/2009/11/12/gomemcached.html#comment-22883032 http://dustin.github.com/2009/11/12/gomemcached.html#comment... Basically, it's about allowing me to express my sequence of writes without wrapping each one in an if block. I could have also done something like return write(x) && write(y) [...] or return write(x, y, ...) but all I really want is to stop writing when a write fails and have the goroutine exit. I've seen a couple people suggest using a channel for this. Containing the write within an object of sorts to contain that boolean would do roughly the same thing. I'd still need to somehow unwind the stack quickly to even know that that channel has something waiting on it.