Re: [go-nuts] ANN: A new package to wrap errors and record a stack trace
Hi!
On Mon, Jan 3, 2022 at 5:34 PM Gaurav Maheshwari
wrote:
> 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 ?
I think you do not want to control stack depth (which is hard-coded at
32), but the depth at which the stack starts. I must admit that one of
the reasons for this package was because I was first extending
github.com/pkg/errors by wrapping its functions, but then those
wrapper functions ended up in all stack traces. But this was a problem
because of me wrapping github.com/pkg/errors itself. But I do not
fully understand your use case through. Maybe open an issue in the
repository to discuss this further there? At first glance I do not see
an easy way to add such parameter to existing functions, but adding a
whole set of other functions might be an overkill. So it really
depends on what is your use case here.
> 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?
That is the same as in github.com/pkg/errors. In Go a package does not
have to export an interface for you to be able to use it, you just
define the same interface with same signatures in you own code. The
difference with github.com/pkg/errors is that the interface is defined
as:
type stackTracer interface {
StackTrace() []uintptr
}
So there is no custom type in the StackTrace signature which allows
one to define this interface without even having to import
gitlab.com/tozd/go/errors.
> Can you please explain this statement as well?
> > Makes sure a stack trace is not recorded multiple times unnecessarily.
github.com/pkg/errors's functions unconditionally recorded a stack
trace every time you called any of its methods, even when the error
you were wrapping already had a stack trace. Most functions in this
package add a stack trace only if the error does not already have one.
The only exception is Wrap which does it again.
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/CAKLmikMJrphARNnwppZsMfsT5c0KJ-bmnCS-eHg5_i7ZHtaheQ%40mail.gmail.com.
Re: [go-nuts] ANN: A new package to wrap errors and record a stack trace
Did you check https://github.com/cockroachdb/errors ? How does it differ from cockroachdb/errors? On Mon, 3 Jan 2022 at 08:05, Mitar 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 -- 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/CAGVdjEgMxhGHTzZrtyHTNz%3DRk6b4uQTRfEnPxtE90U-v--1-hQ%40mail.gmail.com.
Re: [go-nuts] ANN: A new package to wrap errors and record a stack trace
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 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 > 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 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.
Re: [go-nuts] ANN: A new package to wrap errors and record a stack trace
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 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 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 -- 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/CAKLmikPuEWo9uWvXK_A7yq6F6%2BwLzV_hrrD7Kt1pfbPzWMqp6Q%40mail.gmail.com.
[go-nuts] ANN: A new package to wrap errors and record a stack trace
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.
