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

[roger peppe]

On 29 May 2014 20:00, Jeroen Vermeulen <jeroen.vermeulen at canonical.com> wrote:
> 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.

This is the kind of error I have been thinking about.

> 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.

This, on the other hand is interesting, and something I have not
really considered. Thanks for bringing it up. I haven't written code like this,
and I'm not aware of any in the juju-core code base.

Have you got any real-world examples you could point to?

FWIW, this approach is still possible even when error types are
masked by default - all the error stack information is still exposed,
even though convention would suggest that it should not be
looked at, just as it's a useful convention that we should not
base program behaviour on the string contents of error messages.

  cheers,
    rog.