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

[roger peppe]

On 14 May 2014 10:24, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi all,
>
> I took it upon myself to get Rog's errgo library used inside juju-core.

Thanks for doing this.

> Dimiter recently did a hunk of work in the juju-core/errors package to
> have functions to add context to some core error types while keeping
> their type.
>
> What I did was to move this errors package out of juju-core and into its
> own package, and update it to use the errgo as a base.  For those that
> are interested the diff for the errors_test (to show that everything
> works as before) is as shown at the bottom of this email.
>
> I also added in simple methods based on my earlier error handling
> package, but changed them to be based on errgo.  This adds in the
> functions: New, Errorf, Check, Trace, Annotate, Annotatef, Wrap, ErrorStack.

Any particular reason to wrap the errgo functions rather than using errgo
directly? Personally, I see the role of the errors package to be about
specific error classifications (something that errgo tries hard to be entirely
agnostic about), but errgo could, and I believe should, be used directly for all
the more general calls.

Since it's likely that other packages will start to use errgo, and they don't
necessarily want to be importing juju/errors, there are advantages
to using the same error generation and classification style that any
other errgo-using package would use - in particular, it makes the code easier
to manipulate programmatically.

There are also advantages in not having two subtly different APIs
around, even if one is implemented in terms of the other. I believe
we should pick one set of calls and use them consistently throughout
the code base.

BTW, I have a gofix clone which automates 95+% of the changes
to use errgo - it's at code.google.com/p/rog-go/exp/cmd/errfix
It splits the changes into several modules so that the
changes can be made in more-easily verifiable steps.

> I have tested juju/errors with both gc and gccgo and the tests pass with
> both.  Interestingly juju/errgo has a few test failures with gccgo, but
> Dave is looking at them and assures me they are simple fixes.
> As an aside, I do think that any new dependencies we add should pass all
> tests with both gc and gccgo.

Thanks a lot for doing this. I really should install and try gccgo!

  cheers,
    rog.