ANN: A new package to wrap errors and record a stack trace

[Mitar]

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

[Mitar]

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...@gmail.com> wrote:
>
> Did you check https://github.com/cockroachdb/errors ? How does it differ from cockroachdb/errors?

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

[Gaurav Maheshwari]

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.

--

Gaurav Maheshwari

[Gaurav Maheshwari]

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:

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

[Mitar]

Hi!

On Mon, Jan 3, 2022 at 5:34 PM Gaurav Maheshwari
<gaurav...@gmail.com> 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.