What's the current best practice for getting a stack trace from an error passed up from further down in the stack?
E.g. a web server middleware uses recover to catch panics. In the recover, we want the stack trace of the code that created the first error in the stack. On Monday, 3 February 2025 at 20:40:49 UTC-5 Jeremy French wrote: > I don't know if it qualifies as "best practice" but I think it would > certainly qualify as convention to put the error as the last returned > value. It is also extremely common to name the error "err", though that > would have little impact on API consumers as they can rename it whatever > they want. > > It's also quite common at this point to wrap your errors with > fmt.Errorf(), which allows errors.Is() to match the root error, or anywhere > up the error chain, which can be convenient for your consumers. But I think > I would dare to say that it's best practice to only wrap an error if you > have something meaningful to add to it. For example "no such file or > directory" is less helpful than "config: no such file or directory." but > "can't find file: no such file or directory" doesn't add anything. I would > also say that it's (somewhat) considered best practice to keep your errors > terse and written for the developers, rather than flowery descriptive text > written for the end user. If you need text for the end user, translate it > at the point of intercepting the error and doing something with it. > > And of course, I believe Effective Go <https://go.dev/doc/effective_go> has > a bit to say on the subject. > > On Monday, February 3, 2025 at 6:01:59 AM UTC-5 Byungjun You wrote: > >> In Java, checked exceptions allow developers to define in advance which >> exceptions a function can throw. However, it seems that Go does not have >> such a feature. Would it be considered a best practice in Go to document >> the possible errors that an API function can return? Additionally, what are >> some best practices that API providers can follow to help API users handle >> errors effectively? >> > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/38544d86-2f66-4518-baff-5d3141d7d3b0n%40googlegroups.com.
