So, I took a deeper dive into Tim's newly renamed arrar<https://godoc.org/github.com/juju/arrar>package, and compared it to Roger's errgo<https://godoc.org/launchpad.net/~rogpeppe/errgo/errors-package/errors>package.
Before I go into the implementations, I want to write down some goals: 1: Make it easy to wrap errors from deeper in the code with context from the local scope. 2: Mask errors that are merely implementation details from callers. 3: Give a stack trace of the root error for debugging purposes. The packages are very similar in what they're trying to do - maintain an ordered list of errors that represent one logical error to the end user, and make it easy to wrap an existing error in one of their special errors, without losing information about the wrapped error. I think both of them need examples to show how they're intended to be used, but once I played around with them in actual code, they made sense. I also think both of them could use with some name tweaking to make the intent of the code a little more obvious. I like that Roger's package has a concrete type that can be reused, and interfaces you can implement if you don't want to use the base type. I would tend to do the former a lot, something like type NoConfigurationError errgo.Err However, the concept of a Diagnosis seems overly complicated to me. I pretty much never want to encourage people to look at the underlying error, and diagnosis seems to want to do that in some cases. I think what I really want is Roger's errgo package, but with the Diagnosis code removed, and just expose underlying errors through the Cause() method. I'd like to then steal arrar's function for returning a list of the underlying errors (GetErrorStack<https://godoc.org/github.com/juju/arrar#GetErrorStack>), and I like his string formatting better for the stack-trace-lite ( DetailedErrorStack<https://godoc.org/github.com/juju/arrar#DetailedErrorStack>), but I wouldn't bother with formatting parameter, because I honestly will never care. However, I also was an honest-to-god stacktrace<http://golang.org/pkg/runtime/#Stack>available from the root error, because both implementations can miss important information about how you got to the root error that a real stacktrace wouldn't miss. So, that's my answer to which one - a little of both and a little more sprinkled on top :) On Thu, Feb 6, 2014 at 3:04 AM, Tim Penhey <tim.pen...@canonical.com> wrote: > On 06/02/14 14:14, Nate Finch wrote: > > One thing I noticed was that it looked like it wasn't generating an > > actual stack trace ever. I think that's pretty critical to knowing how > > you got to the spot where you got the error. > > I made the default behaviour of the error message to match exactly what > we have now. > > There is, however, an extra method that you can use to get the traceback > for logging purposes. > > Also, out of respect for Roger's errgo package, this is being renamed > and moved under the juju organisation. I'm going to submit a branch > shortly that will move the imports and names, but the actual repo is > there now. I also had to fix some things for gccgo. > > http://github.com/juju/arrar > > The name was changed to kinda fit "annotated error", but also fits if > you think of a pirate trying to say "error" > > arrar.DetailedErrorStack(err, arrar.Default) will return the traceback > that shows the full path, with each location on a different line. The > second parameter allows different prefixes so you could indent it if you > like, and also to control the number of path elements in the filename > that you are interested in. > > I plan to write something more about that will be put into the README.md > that will show more usage. > > Tim > > > On Feb 5, 2014 7:29 PM, "Martin Packman" <martin.pack...@canonical.com > > <mailto:martin.pack...@canonical.com>> wrote: > > > > On 04/02/2014, Tim Penhey <tim.pen...@canonical.com > > <mailto:tim.pen...@canonical.com>> wrote: > > > > > > Docs need a little work. > > > > Can you give us an inspirational example of an error message made > > clearer at least? > > > > I know Roger has hacked on something along these lines in the past, > > I'm curious to hear his thoughts on your stab at tracebacks versus > the > > approach he tried. > > > > Martin > > > > -- > > Juju-dev mailing list > > Juju-dev@lists.ubuntu.com <mailto: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
