Re:New in Go 1.20: wrapping multiple errors
by cube2222 on Sunday December 11, 2022 @09:19AM
(#33943411)
That is a fair point and it's why I use errcheck[0].
Re:New in Go 1.20: wrapping multiple errors
by Smaug123 on Sunday December 11, 2022 @09:50AM
(#33943648)
Magic! I just checked, and this found the bug in a Go tool I use that bit me a couple of months ago, which I'm still smarting from. Thanks!
Re:New in Go 1.20: wrapping multiple errors
by cube2222 on Sunday December 11, 2022 @09:57AM
(#33943708)
Glad I could help!
In general, I recommend using golangci-lint[0], which aggregates a ton of useful linters like this one.
Re:New in Go 1.20: wrapping multiple errors
by cjglo on Sunday December 11, 2022 @10:27AM
(#33943949)
I don’t like Go error handling, but exceptions are terrible and not better.
Rust/Zig/Swift approach is definitely the best.
Re:New in Go 1.20: wrapping multiple errors
by kaba0 on Sunday December 11, 2022 @03:44PM
(#33947288)
Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).
Re:New in Go 1.20: wrapping multiple errors
by cjglo on Monday December 12, 2022 @11:17AM
(#33956388)
Not analogous.
Rust-style result types continue the normal control flow.
Any exception thrown deep into a function can be very hard to debug. The normal line of execution is stopped, even without a return, and if it’s a checked exception it can “bubble up” to higher functions despite nothing signifying a return, just a marker saying somewhere this can throw an exception.
Exceptions are terrible.
Re:New in Go 1.20: wrapping multiple errors
by kaba0 on Tuesday December 13, 2022 @05:38AM
(#33966992)
This is literally the exact same thing. Exceptions are not gotos. They bubble up one method at a time, and can be handled at any level you want. Matching on a result type is literally the same thing as putting in inside a try-catch block. Putting a ? macro at the end is literally the default behavior. You can handle it on as tight/wide scope as you wish, plus you also get a must-have stacktrace — so your debugging is just looking at where the exception originated from.
This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime will let you know loudly and fatally when you've got garbage; in a language with a type system that admits a Result type, the compiler will forbid compilation unless you note that you're throwing away the error (which might be a single character of syntactic sugar, it need not be verbose!). But Golang and C and friends are the languages where you silently get garbage if you forget to do the due diligence that machines are perfectly capable of doing for you, and it makes me extremely sad every time I see a bug of this nature.