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

[Tim Penhey]

On 23/05/14 02:47, roger peppe wrote:
> 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.

Sure.  There were several reasons that kept me away from using errgo
directly or modifying errgo.

1) Probably the most important, I don't feel that errgo is a 'juju'
library but very much a personal library of yours, one that you have
very strong feelings about, and I feel that proposing changes that
fundamentally change how it behaves will get bogged down in
bike-shedding and disagreement.  I was wanting to get the behaviour that
we wanted, and I found a way to get that behaviour without touching
errgo, so I went that way.

2) The default behaviour of errgo to mask the underlying cause was not
the behaviour that juju wants.  For example the Notef function returns
an error where the Cause of that error is different to the Cause of the
error that is being annotated.  I know that there is NoteMask, but that
isn't what I think of when all I want to do is add a note.

3) I found the functions in errgo to be confusing when what I wanted was
three simple things: add stack information, annotate the error (and add
stack info), or change the cause (and add stack info).  There is no way
to just change the cause with errgo without providing some annotation,
and I think that if you are a user of the library and wanting to provide
a more detailed error to describe the problem, then that error is likely
to contain all the information that you want to see, and as such,
forcing them to also add a message is not needed.

4) The string representation of the error was not what we wanted with
juju.  The errgo implementation walks up the entire error stack
outputting annotations up to the top, and then the underlying error.
The behaviour we wanted was to walk up the annotations and stop when the
cause of the error changes and write out the cause.  That way actually
changing the cause of the error as it is passed down but keeping the
entire call stack gives a string representation of the actual (most
recent) cause of the error, not the original, and yet the entire call
stack could be output.


Now all credit to errgo in that it provides a flexible error handling
mechanism that I was able to provide all the necessary functionality
that we desired without modifying it.


Getting the stack trace information accessible to debugging and logging
was my first priority. The errgo discussion started almost a year ago
and we still hadn't gotten things merged and it was my understanding
that a key reason for that was a difference of opinion around the 'keep
the cause the same' vs. 'the cause of the error is different' default
behaviour.  I was not interested in getting into yet more discussions
and time delay around getting the functionality we want into the juju
libraries.

I was wanting to move the error package out of juju-core any way so it
could be used by other projects (more easily), and it just seemed timely
to add the, in my opinion, simpler interface to that package.

I'm not against changing errgo, but I didn't want to block the work on
that discussion happening, especially when in the past we have just
agreed to disagree, and that isn't a bad thing.  Differences of opinion
are good and challenging.


Tim