Thanks for the detailed comparison. I do agree that a leaner library as a base library is better for a lot of use-cases.
Few questions/suggestions on the APIs: 1. Do you think it would be better to expose methods which can allow to control Stack depth, e.g. it is quite common to wrap external libraries in a thin-proxy library in large codebases but dropping proxy layer from stacktrace would be useful for readability. Similar to crdb's WrapWithDepthf ? 2. Given stackTrace interface is not exported, how could a user access the Stack trace associated with an error programmatically? The use-case I have in mind is to configure structured logging such that stack trace associated with an error goes in a separate log key? Can you please explain this statement as well? > Makes sure a stack trace is not recorded multiple times unnecessarily. On Mon, 3 Jan 2022 at 17:50, Mitar <mmi...@gmail.com> wrote: > Hi! > > Yes, I have. My view is that both github.com/pkg/errors and > gitlab.com/tozd/go/errors aim at being more or less a drop-in > replacement for core errors, but adding stack traces to errors. Since > Go has now Errorf which can wrap existing errors to augment their > messages, the utility functions in github.com/pkg/errors and > gitlab.com/tozd/go/errors are not really necessary, but they still > make some common cases easy. So my view is that these two packages > could be something which could be used in a wide range of packages to > produce errors, when the package also wants to return a stack trace > with the error. > > On the other hand, github.com/cockroachdb/errors has so many features > that to effecticelly use it one has to coordinate around the codebase > how exactly different features are used to get consistency. So it is > less useful in my opinion for 3rd party packages and more as something > you would use in your own large codebase (which you more or less > control). But it has all possible features you might ever want. Maybe > it could be cool if github.com/cockroachdb/errors would be built on > top of gitlab.com/tozd/go/errors, to use when you need all those > additional features. > > Additionally, I am personally not too convinced about storing end-user > hints into errors themselves. Maybe that works for some people, but to > me errors are something useful to control program flow and to debug by > developers, while showing hints to end users is generally something > one has to do separately (e.g., because you have to translate that > hint anyway to the user's language). So to me a pattern I prefer, and > gitlab.com/tozd/go/errors enables, is to have a set of base errors > (e.g., io.EOF) which you then augment with the stack trace at the > point where they happen, and then when you are handling errors you use > `errors.Is` to determine which of base errors happened and map that to > a message for the end user, in their language. So in a way, > github.com/cockroachdb/errors has too much stuff for me, so I prefer > something leaner. > > > Mitar > > On Mon, Jan 3, 2022 at 7:27 AM Gaurav Maheshwari > <gaurav.m.i...@gmail.com> wrote: > > > > Did you check https://github.com/cockroachdb/errors ? How does it > differ from cockroachdb/errors? > > > > On Mon, 3 Jan 2022 at 08:05, Mitar <mmi...@gmail.com> wrote: > >> > >> Hi! > >> > >> I have recently published a new package which provides errors with a > >> stack trace, similar to now archived github.com/pkg/errors, but > >> attempting to address many issues the community has identified since > >> and updating it to new Go features. It is almost compatible with > >> github.com/pkg/errors codewise and very familiar human wise. > >> > >> Now you can use Errorf to both wrap an existing error, format the > >> error message, and record a stack trace. > >> > >> https://gitlab.com/tozd/go/errors > >> > >> Check it out. Any feedback is welcome. > >> > >> > >> Mitar > >> > >> -- > >> http://mitar.tnode.com/ > >> https://twitter.com/mitar_m > >> > >> -- > >> 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. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAKLmikOVd%3DaV01QQf8xUE5vOxqarz7dsrit0V3pgT_XsaQuGow%40mail.gmail.com > . > > > > > > > > -- > > Gaurav Maheshwari > > > > -- > http://mitar.tnode.com/ > https://twitter.com/mitar_m > -- Gaurav Maheshwari -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGVdjEiDb-r1x%2B3CVFU0zzmagYDZaPRWPbVptuqgTa6n1muz7Q%40mail.gmail.com.
