4 ms·
> If a function fails, then you need to handle its failure And this is exactly where Go fails, because it allows you to completely ignore the error, which wi
by billmcneale 1y ago
> If a function fails, then you need to handle its failure
And this is exactly where Go fails, because it allows you
to completely ignore the error, which will lead to a crash.
I'm a bit baffled that you correctly identified that this is a requirement to produce robust software and yet, you like Go's error handling approach...
- haiku2077 1y agoOn every project I ship I require golangci-lint to pass to allow merge, which forces you to explicitly handle or ignore errors. It forbids implicitly ignoring errors. Note that ignoring errors doesn't necessarily lead ti a crash; there are plenty of functions where an error won't ever happen in practice, either because preconditions are checked by the program before the function call or because the function's implementation has changed and the error return is vestigal.
- etra0 1y agoYet the problem still has happened on big projects: https://news.ycombinator.com/item?id=36398874 https://news.ycombinator.com/item?id=36398874
- 9rx 1y agoPedantically, every single one of those examples are a case of unspecified behaviour, not bugs. There may be no meaningful difference to the end user, but there is a big difference from a developer perspective. Can we find cases of the same where behaviour was specified?
- pphysch 1y ago> which will lead to a crash No it won't. It could lead to a crash or some other nasty bug, but this is absolutely not a fact you can design around, because it's not always true.