3 ms·

> 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

> 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.

cube2222 4y ago
That is a fair point and it's why I use errcheck[0]. [0]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck
- Smaug123 4y ago
  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!
  - cube2222 4y ago
    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 https://github.com/golangci/golangci-lint
cjglo 4y ago
I don’t like Go error handling, but exceptions are terrible and not better. Rust/Zig/Swift approach is definitely the best.
- kaba0 4y ago
  Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).
  - cjglo 4y ago
    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.
    - kaba0 4y ago
      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.

cube2222 4y ago

That is a fair point and it's why I use errcheck[0]. [0]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck

Smaug123 4y ago
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!
- cube2222 4y ago
  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 https://github.com/golangci/golangci-lint

cjglo 4y ago

I don’t like Go error handling, but exceptions are terrible and not better. Rust/Zig/Swift approach is definitely the best.

kaba0 4y ago
Exceptions are much better, especially checked ones (which are analogous to Rust-style result types).
- cjglo 4y ago
  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.
  - kaba0 4y ago
    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.