4 ms·
> the res, _ := … error handling punt and wanted to confirm that lack of even a warning Warnings don't exist in go build, because warnings are ignored by peopl
by lloeki 8y ago
> the res, _ := … error handling punt and wanted to confirm that lack of even a warning
Warnings don't exist in go build, because warnings are ignored by people. IIRC there are linters that do highlight those if you care for it and want hints about things to check.
There are legitimate use cases of swallowing error return values†, and if you throw warnings intros cases, then you can't tell the difference between a legit warning and a legit use case that shouldn't warn.
> none of the examples on the golang.org homepage handle error. You appear to have to go into the fourth section of the language tour to find error handling first being discussed 19 pages into the ”Methods and interfaces” section
Skimming over the fact that this is a "Tour of Go", not a full-blown tutorial, there is not a single call that would return an error before the page you mentioned. There are ok return values for map fetches and type assertions before that though, but they're just printed out, and the same pattern continues afterwards. Those are focused code snippets to show features and get the vibe of things. I certainly wouldn't expect from a tour (for any language) to be the equivalent of The Go Programming Language book, nor Effective Go[0].
[0]: https://golang.org/doc/effective_go.html#errors https://golang.org/doc/effective_go.html#errors
† It happens that by design you may have the guarantee that e.g ParseInt will work because you're under full control of the input type and/or value.
- acdha 8y ago> Warnings don't exist in go build, because warnings are ignored by people. Okay, make them errors - an unused import is an error and the risk is orders of magnitude lower. > There are legitimate use cases of swallowing error return values†, and if you throw warnings intros cases, then you can't tell the difference between a legit warning and a legit use case that shouldn't warn. Nobody is saying there aren’t cases where you can legitimately ignore them. My position is just that it should require intent rather than being the default: you should have to access any error type at least once after assignment, even if it’s just to intentionally ignore an expected error (which is also important for confirming that the error you’re ignoring is the one you expected and not something else). Regarding examples, yes, there’s a balance of not overcrowding examples but people retain early lessons for long periods of time. Since almost all non-trivial Go programs work with things like files and networks, it should be more prominent because the language repeats the C style approach of leaving error handling up to programmer diligence and that means you need to develop the habit from the beginning because the language doesn’t have any other protections.