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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
