2 ms·
> An error signals that a non-error value you were relying on will not be available. Except the non-error value should always be available, even if that means
by randomdata 3y ago
> An error signals that a non-error value you were relying on will not be available.
Except the non-error value should always be available, even if that means relying on the zero value. Zero values should be useful. An error state is an independent state. It should also be useful without any other values.
While the caller may choose to use the error state to make decisions about other state, it is faulty API design to force that upon the caller.
- erik_seaberg 3y agoMany domains have no meaningful zero value. If “getUserByID” returns a fake user, anything you do with him will be incorrect, if you don’t panic and die (as zeroes of builtin types often do).
- randomdata 3y ago> If “getUserByID” returns a fake user Logically, getUserByID returns nil when there is no user, not a fake user. The caller can then check for its nil-ness without needing to consider the error value. nil is a useful value. For better or worse, nil is how Go convention represents the absence of a value. In fact, convention sees error also rely on nil to be useful in the very same way. It's funny how people completely forget how to write software as soon as they see the word error. Why is that?