At first I didn't like this idea, but the README has converted me to the
possibilities. I have to admit I have a strong aversion to interface{}, and
a map as well, but a lot of the other features are very interesting. I
think, in a larger project, this may be just the thing for structured
logging, though I tend to roll my own.
The single mindedness of errors in go is actually something good IMHO,
though sometimes we'd like to stick more data in, is errors.With("blah",
"blah").Wrap(other_error) Really different than
errors.New(fmt.Sprintf("blah=blah because %s",other_err))? I guess it seems
more pleasing to use a fluid interface if you come to go from a language
that emphasized that, but sometimes the ease of writing occludes the ease
of reading, or reasoning. Also - who has time to learn Yet Another Library.
Yet in a large application, say an API or some kind of webservice,
structured logging and a logging/error API not only has a place, but would
be a boon to the project all. I think it's a great addition to the
ecosystem, and good as a tool for people to use if and when they need it. I
know I'll give it a go on my next project that is a webservice, so this
might be just the thing...
/Jason
Le mercredi 12 octobre 2016 05:34:48 UTC+2, John Jeffery a écrit :
>
> I have been following the progress of package github.com/pkg/errors, and
> have put it to much use. Thanks very much to Dave Cheney and the other
> authors.
>
> A few months ago an interesting issue was raised along the lines of being
> able to attach arbitrary data to the error (
> https://github.com/pkg/errors/issues/34). Some interesting discussion
> ensued, and in the end Dave decided not to add this feature to the package,
> and gave some very good reasons for his decision. This is all good and I
> think I learned a lot from the discussion.
>
> All the same I became quite interested in the idea that, if key/value
> pairs of information could be attached to errors as they "bubble up" the
> stack, then this could provide an alternative to passing a logger down
> through the call stack, adding context along the way until something
> actually has to be logged.
>
> So given that the github.com/pkg/errors package was not going to include
> the feature, I decided to have a go at building an errors package that
> provides a minimal API for programs that make use of structured logging.
> The result is at https://github.com/jjeffery/errors. The API has a very
> small surface area, and I have found it pleasant to use in my own projects.
>
> Of course there are many other popular error handling packages, and
> github.com/pkg/errors combines the best ideas of many of them. I think it
> is a stated goal that github.com/pkg/errors be considered for inclusion
> in the standard library at some point. I just have not seen structured
> key/values integrated into error handling in quite the same way before, and
> thought I'd mention this work and ask for community feedback.
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
