Re: [go-nuts] Best Practices for Error Handling in Go APIs

Watch out for that article is pretty old, predating stdlib wrapping etc. On Thu, 6 Feb 2025 at 14:29, Byungjun You wrote: > Hi Mike, thank you so much for sharing your thoughts and all those > resources with concr

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Hi Mike, thank you so much for sharing your thoughts and all those resources with concrete examples. Those really help me to understand how errors in go work and how it is different from errors in Java. Based on what you've shared, here's how I understand it: In essence, because an error in Go

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Hi Uzondo, Thanks for the comments. > On Feb 5, 2025, at 3:44 PM, Uzondu Enudeme wrote: > On the naming I also thought TraceError could be called StackError so that > NewStackError would return *StackError. > Maybe we can just rename it to be NewTraceError() since it returns > *TraceError.

Re: [go-nuts] Best Practices for Error Handling in Go APIs

Hi Mike, Good stuff and thanks for sharing. P.S. I threw this together to answer the question, but if anyone else > notices something I missed or did wrong, it would be great if you could > mention it as I would actually like to use this code moving forward. One observation is that the impleme

Re: [go-nuts] Best Practices for Error Handling in Go APIs

> On Feb 4, 2025, at 4:59 PM, Darren Grant wrote: > > 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 c

Re: [go-nuts] Best Practices for Error Handling in Go APIs

> On Feb 3, 2025, at 6:01 AM, 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

[go-nuts] Best Practices for Error Handling in Go APIs

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