4 ms·

> I don't see how anyone can see this as anything other than a big ugly wart on the face of the language. Would you be satisfied if the compiler forced you to

by geoka9 5y ago

> I don't see how anyone can see this as anything other than a big ugly wart on the face of the language. Would you be satisfied if the compiler forced you to check error returns?

cytzol 5y ago
I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a long way to allay my worries with Go. I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmatism must win in this case. [1]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck [2]: https://github.com/gordonklaus/ineffassign https://github.com/gordonklaus/ineffassign [3]: https://pkg.go.dev/builtin#error https://pkg.go.dev/builtin#error
- geoka9 5y ago
  There's a proposal for the Go 2 draft that addresses this: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803 https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf...
nprateem 5y ago
Why should we have to waste our time doing something the machine can do? I normally only care about handling errors in 5% of places. The rest of the time it's just returning them. Life's too short

by geoka9 5y ago

> I don't see how anyone can see this as anything other than a big ugly wart on the face of the language. Would you be satisfied if the compiler forced you to check error returns?

cytzol 5y ago

I'd be really happy with that! Building the functionality of errcheck[1] and ineffassign[2] into the compiler — or at the very least, into govet — would go a long way to allay my worries with Go. I think the reason they don't do this is that it's a slight (albeit a very tiny one) against Go's philosophy of errors being values, just like any other. While the `error` type is standard and used throughout Go source code, it still just has a simple three-line definition[3] and is not treated as a special case anywhere else; there is nothing stopping you from returning your own error type if you wish. A third-party linter could simply check for the `error` type specifically, but the first-party tools should not, and there's nothing like Rust's `#[must_use]` attribute that could be used instead. I respect Go's philosophy, but I feel like pragmatism must win in this case. [1]: https://github.com/kisielk/errcheck https://github.com/kisielk/errcheck [2]: https://github.com/gordonklaus/ineffassign https://github.com/gordonklaus/ineffassign [3]: https://pkg.go.dev/builtin#error https://pkg.go.dev/builtin#error

geoka9 5y ago
There's a proposal for the Go 2 draft that addresses this: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803 https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md https://go.googlesource.com/proposal/+/master/design/go2draf...

nprateem 5y ago

Why should we have to waste our time doing something the machine can do? I normally only care about handling errors in 5% of places. The rest of the time it's just returning them. Life's too short