Usage of cockroachdb/errors package

[mariuskimmina]

I found that we are currently using both cockroachdb/errors as well as the standard library errors package.

rg "github.com/cockroachdb/errors" | wc -l
109

rg "\"errors\"" | wc -l                                                                                                      
292

Both of these numbers are from the cnquery repo.

I was wondering if there are specific cases in which we needed the cockroachdb/errors package over the standard library ones?

I haven't looked at all the cases in which we use cockroachdb/errors but in the cases I looked at I often found that we only called errors.New() anyway - which should behave the same as standard librarry errors.New() if I am not mistaken. We do seem to make use of errors.Wrap() from the cockroach module in some places but I think these could also be done with fmt.Errorf().

Essentially I am trying to figure out if there is a strong reason to keep using cockroachdb/errors over the standard library errors package or if it could be worth doing a refactor to get rid of this dependency.

[chris-rock]

We used cockroachdb/errors mostly for errors.Wrap() which the native go package has not allowed before 1.20. With the introduction of https://tip.golang.org/doc/go1.20#errors, also see here https://blog.devgenius.io/wrapping-multiple-errors-in-go-1-20-78163ef5fc2c we actually can move back to the native error package for most cases.