mikebell-org/go-couchdb — pull request #1 by hasenj (2012-08-16 18:22:51+00:00)
Title: Functions should always return error, not a custom error class

This is the idiomatic go way, otherwise we get into trouble.

Notice that `error` is an interface.

var er1 *CustomErrorClass
var er2 error

er1 = nil
er2 = er1

er2 is not nil, the nil gets sort of "boxed" so it appears as if you
have an error even though it's nil:

if er1 != nil {
// doesn't get executed; er1 is nil
log.Fatal("We have an error")
}

if er2 != nil {
// er2 is not nil, so this block executes
log.Fatal("We have an error")
}

Why, you ask, does Go behave this way?

Because the fact that er1 is of type *CustomErrorClass is information
that needs to be present in the er2 interface

er1.Error() is a valid expression even though er1 is nil
and if so, er2.Error() is also a valid expression, it will call the
Error() method on the CustomErrorClass type with nil as a parameter,
which could very well work, as in:

func (t *T) Error() string {
return "hi"
}

Thanks to 'smw' and 'kmapped' from #go-nuts for explaining this to me