I agree with Roger, I don't think a wrapper around Errgo is the right way to go. If we don't like the way errgo behaves, we should change it. It's our package, let's have it work the way we want it to work.
On Thu, May 22, 2014 at 10:47 AM, roger peppe <rogpe...@gmail.com> wrote: > On 14 May 2014 10:24, Tim Penhey <tim.pen...@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. > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
