Comment by Smaug123 | Hacker News Reader

Comment by Smaug123 | Hacker News Reader

Parent Full thread

> I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere…

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.

That is a fair point and it's why I use errcheck[0].

[0]: https://github.com/kisielk/errcheck

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!

Glad I could help!

In general, I recommend using golangci-lint[0], which aggregates a ton of useful linters like this one.

[0]: https://github.com/golangci/golangci-lint

I don’t like Go error handling, but exceptions are terrible and not better.

Rust/Zig/Swift approach is definitely the best.

Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).

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.

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.

Reply on news.ycombinator.com