Yes, of course I'm quite familiar with Go 1.13's error capabilities. github.com/pkg/errors is still useful when one wants to attach stack traces to errors.
But this leaves my question open: What are alternatives to wrapping errors? (Other than passing around errors with no semantic meaning, as was the case before wrapping was widespread) On Thursday, December 23, 2021 at 8:51:20 PM UTC+1 Kevin Chowski wrote: > 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/a3afcdd9-3dd5-4bb6-84ef-8b05667519a0n%40googlegroups.com.
