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...


Le mercredi 12 octobre 2016 05:34:48 UTC+2, John Jeffery a écrit :
> I have been following the progress of package, 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 (
> 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 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 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 
> combines the best ideas of many of them. I think it 
> is a stated goal that 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 
For more options, visit

Reply via email to