Comparing Error packages

roger peppe roger.peppe at canonical.com
Wed Feb 12 18:54:45 UTC 2014


As a point of information, I spiked a large chunk of the juju
source code to use errgo. Here's what it looks like.

https://codereview.appspot.com/62230043

It actually felt like the process added significant value to
the code - some error-to-action paths which were previously implicit
and sometimes ambiguous have become more evident
(and one or two potential bugs have surfaced).

Much of the process was actually independent of the errors
package used - the most significant issues encountered were
not due to the "mask error diagnosis by default" behaviour of
errgo.

If this seems reasonable I could move it forward.
(that would probably involve splitting it up into 5 or 6
separate,  but still large, MPs)

  cheers,
    rog.

On 11 February 2014 10:41, roger peppe <rogpeppe at gmail.com> wrote:
> On 10 February 2014 12:16, Nate Finch <nate.finch at canonical.com> wrote:
>> I propose we make a small sample program that exercises error returns in
>> several typical ways, including the non-trivial scenarios, and then make one
>> implementation for each competing error package, so we can see how they work
>> out in real code.
>>
>> The code can be very terse, since there's no need for real logic other than
>> control flow and error handling, but it can involve things like passing an
>> error back through several levels, sending an error over a channel from one
>> goroutine to another, masking errors we don't want exposed, handling third
>> party errors, and using internal custom error types.
>>
>> I think this is the best way to compare the error packages, since we'll see
>> first hand how they would look being used in real code.
>
> I think that the best way to see how they look in real code is
> to change some of our real code to use them.
>
> I've done that with errgo, and it's very interesting
> to see what actual issues present themselves in practice.
>
> As a starter for 1 point, try the utils/fslock package.
>
> All occurrences of fmt.Errorf should be changed to use the
> new primitives, and any instances of
>
>     if err != nil {
>         return err
>     }
>
> should be changed to wrap the error appropriately.
> All tests should pass, obviously :-)



More information about the Juju-dev mailing list