Re: [go-nuts] io.Reader can return (n, err), both non-zero

+1 I’d love to hear more about the motivation behind the io.EOF as an error. And why select a strategy to prefer *no* *discriminated unions* for the error results? Why transport non-error information in error values (io.EOF, 'http.ErrServerClosed)? “Normal” vs. “error” [control flow] is a

Re: [go-nuts] assert library with generics?

I’m biased as well. FWIW, this is a subpackage of the error handling solution, err2 . The assertion pkg is proven to be a precious tool for many projects. It is unique because it can be used both for

Re: [go-nuts] Re: Error handling

t;>>>> assignment >>>>>> expression which assigns multiple values, does it only look at the last >>>>>> value? (Again, that was not specified) >>>>>> >>>>>> - does it always test a variable called "err"? The origin

[go-nuts] Re: Error handling

IMHO, you have used the irrelevant example (== 2nd code block) from Russ Cox's paper. The paper says: > This code is not nice, not clean, not elegant, *and still wrong:* like the previous version, it does not remove dst when io.Copy or w.Close fails. I want to compare your proposal with the

Re: [go-nuts] [RFC] Yet another proposal for Go2 error handling

The sample block below is what we can have without any language updates. I will let you decide your thoughts about its readability, but please note that even the error strings are built automatically—error propagation with error traces, of course. Deferred error handling seems to clarify

[go-nuts] Re: Error Handling

A package err2 helps you to implement the `errReturn` even though Go doesn't have macros or can return from the function enclosing the function checking the error. Please see the playground that does exactly that: https://go.dev/play/p/GvXFU1LbVvs However, I

[go-nuts] Re: Error Handling Question

Hi, On Friday, October 21, 2022 at 12:14:52 AM UTC+3 dple...@google.com wrote: > > var x0 float > try { >x0 = check DoSomeMath(check FetchSomething(), check ComputeSomething()) > } handle err { >log.Info("Unable to estimate initial approximation, defaulting to 1...") >x0 = 1 > } > //

[go-nuts] Re: Generic error handling with panic, recover, and defer

Thanks for mentioning https://github.com/lainio/err2. I'm the author of the package. Maybe a few words about it would be ok. We could say that the err2 package is one of the most important libraries in our corporation's use. It's over three years old by now, and we have used it both for

[go-nuts] Re: “Normal” vs. “error” (control flow) is a fundamental semantic distinction

Thank you! Indeed, the selected names follow the try/catch idiom, and with the err2 , you can write code that includes non-local control flows. I hope that err2 is not confused with exception handling. The Go2 try-proposal

Re: [go-nuts] uber handler to collect stacktrace when program crashing

If you write a wrapper, please look at the err2-package . It's an error-handling package, but we needed to build a panic-safe system with automatic stack tracing. Traces are context optimized as well. Here's a playground demo

[go-nuts] “Normal” vs. “error” (control flow) is a fundamental semantic distinction

Hi all, I thought now was the time to go public. The automatic error propagation is possible with the help of a simple Go package, and it has been about three years now: func CopyFile(src, dst string) (err error) { defer err2.Returnf(, "copy %s %s", src, dst) r :=