Proposed new dependency: github.com/juju/errors (and github.com/juju/errgo)

[Jeroen Vermeulen]

On 2014-05-29 09:50, roger peppe wrote:
> On 29 May 2014 04:03, Tim Penhey <tim.penhey at canonical.com> wrote:

> Errors are worth treating specially here because they're
> they pass up through multiple layers, so it's very easy to break abstraction
> boundaries by relying on specific error types. I believe it's very important
> to *think* about the possible errors that can be returned from a given
> function, and not just throw up our hands and say "you guys 5 layers down,
> why don't you just communicate *arbitrary stuff* to the guy 3 layers above".

It may help to consider this as two problems.


One: caller needs to know about a specific failure — e.g. because it's a 
failure to the callee but not to the caller.  Definitely part of the 
contract.  You either:

(a) define a super-specific error (exception class, error code, etc.), or

(b) document that standard error X means failure Y in this case, and the 
caller picks up the error as close as possible to its origin.

With these errors you have to make sure that the information isn't 
diluted as it propagates, but usually you don't have to take it too far 
up the call chain.


Two: a caller can deal better with some errors, given more detailed 
information.  You can help by attaching more information to the error 
(tags, taxonomy, properties) but only on a best-effort basis.  You 
accept that you don't know exactly which errors can come out of the code 
further down.

For example, if you're writing code which speaks to another program over 
the network, you may want to know: is this connection still usable?  Do 
I know what happened to the operation I requested?  Were we able to 
connect in the first place?  Am I doing something that shouldn't ever 
work, such as mis-spell a command?

With these errors you act on the best information you have, but you can 
always just fail.


Jeroen