Have you seen https://go.dev/blog/go1.13-errors?
If one wants to use error unwrapping, these days generally it is suggested to use the functionality from the standard package "errors" (or fmt.Errorf) rather than some third-party package. That way everyone does it the same way, making third-party packages more composable by default. I personally wrap errors with fmt.Errorf and the %w verb when I want to add additional context to some error I received, and the root cause of why my function failed is *precisely* the same as the 'error' value I received. This is less often than I used to think, and it is definitely a maintenance risk when this error comes from another package: if that package changes what error type it returns, that may break some other part of my code. (that risk is perhaps one reason why folks choose not to wrap errors by default, though note that errors from Go's stdlib are less likely to change over time than some random third-party library.) In general, I prefer to wrap errors that come from a package that I own (again assuming the root cause is exactly the same AND I want to add some annotation), and prefer not to wrap errors that come from a package owned by someone else. But neither are hard rules for code I write or review. One last thought is: if you never unwrap an error, there are fewer good reasons to ever wrap them. If you want to unwrap them, then it obviously starts to make sense to wrap some :) On Thursday, December 23, 2021 at 5:59:22 AM UTC-7 fli...@flimzy.com wrote: > I was recently catching up on the latest state of the > github.com/pkg/errors package (https://github.com/pkg/errors/issues/245), > when I noticed that Dave Cheney said: > > > I no longer use this package, in fact I no longer wrap errors. > > I'm curious what approach Dave uses now, but unless/until he writes on the > topic, I'm also curious what other approaches people use for clean and > cohesive error handling and reporting. > > If you don't wrap errors, how do you ensure meaningful error handling and > reporting in your application? > > Thanks, > Jonathan -- 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/28e77ea4-0a53-4e13-8cf6-d4e25d3c2e5cn%40googlegroups.com.
