On 28 May 2014 19:40, Nate Finch <[email protected]> wrote: > I think the main problem with errgo as it exists, is that it is very awkward > to allow error type information to pass through: > > return errgo.Mask(err, errgo.Any) > > This line is very misleading. It's saying - mask the error type, except > wait, actually don't mask the type. It's never a good idea to use a > function to do the opposite of what it's name says it does.
That's partly why I originally called the function "Wrap", but was persuaded to change it to Mask by popular request. And, I've said this before and I'm sure I'll say it again - it's actually very rare to need to return *any* error type information to pass through. When I changed all of juju to work this way, there were about 5 occurrences out of hundreds, and all were for good and understandable reasons. > Instead, it would be much better to have a method like this: > > errgo.MaintainErrorTypeAndAddTraceback(err) > > (with a better name, obviously, but that's not the point) We could just call it "Wrap". > For the record, I still find the API of errgo to be baffling without a long > ramp up period. Having both an underlying error and a cause is hard to wrap > my head around. I finally managed to load it all up out of long term > storage, so I get it again... but it's not a terribly easy package to > understand, in my opinion. I think this is a valid criticism. I agree that having two entirely orthogonal errors is awkward (and Tim's struggles with producing an intuitive error message demonstrate that). I have been toying with the idea of always maintaining a single error stack, but noting the cause by keeping track of its depth in the stack. So to change the cause, you push an error on the stack that has a cause-depth of zero. If you don't need to change the cause, you push an error that has a cause-depth of one more than the cause-depth of the current top-of-stack. To extract or check the cause, you traverse cause-depth levels down the stack and return the error found there. (To make this more efficient, you could store the cause at each level) That means that the cause can be annotated by simply emphasising (with an asterisk or whatever) the error in the stack that's the current cause. The API could remain largely the same, with the exception that WithCausef would go. We'd probably unexport the Underlying_ and Cause_ fields from the Err struct type too. I think I quite like this idea - what do you think? -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
