I propose we change the name of the package to something other than errgo,
so that Roger can keep his name, and we can make the behavior whatever fits
best for Juju. Yes, we should make it a general-use package, but it should
be designed for Juju, meeting our needs. Roger can post errgo wherever he
wants and make it work exactly the way he wants it to work.
I think that it's neither useful nor a good idea to write *and maintain* a
package under the flag of Juju that we don't like the behavior of.
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.
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)
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 don't think there's any need to debate passing type information through
or not... that's something we can do with any package we're considering. I
think we're agreed that we should maintain the current behavior with the
new package just adding tracebacks, and then we can slowly introduce
behavior changes as we decide we need them.
-Nate
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
