4 ms·
Go can't really express the Result<T> approach. In Go, it's up to you to remember to check result.HasError(), just like it's up to you to check if err != nil. I
by et1337 6y ago
Go can't really express the Result<T> approach. In Go, it's up to you to remember to check result.HasError(), just like it's up to you to check if err != nil. If you forget that check, you'll try to access the Data and get a nil pointer exception.
The Result<T> approach prevents you from accessing Data if you haven't handled the error, and it does so with a compile-time error.
Even with Go's draconian unused variable rules, I and my colleagues have been burned more than once by forgotten error checks.
- jatone 6y agothere are linters that will help you with that. https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck https://golangci-lint.run/usage/linters/ https://golangci-lint.run/usage/linters/ has a solid set of options.
- nimish 6y agoI just wish the linter was integrated into the compiler. And that code that didn't check would simply not compile