On 10 February 2014 12:16, Nate Finch <[email protected]> wrote:
> I propose we make a small sample program that exercises error returns in
> several typical ways, including the non-trivial scenarios, and then make one
> implementation for each competing error package, so we can see how they work
> out in real code.
>
> The code can be very terse, since there's no need for real logic other than
> control flow and error handling, but it can involve things like passing an
> error back through several levels, sending an error over a channel from one
> goroutine to another, masking errors we don't want exposed, handling third
> party errors, and using internal custom error types.
>
> I think this is the best way to compare the error packages, since we'll see
> first hand how they would look being used in real code.
I think that the best way to see how they look in real code is
to change some of our real code to use them.
I've done that with errgo, and it's very interesting
to see what actual issues present themselves in practice.
As a starter for 1 point, try the utils/fslock package.
All occurrences of fmt.Errorf should be changed to use the
new primitives, and any instances of
if err != nil {
return err
}
should be changed to wrap the error appropriately.
All tests should pass, obviously :-)
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
