4 ms·
> If you're given an easy way out, a simpler way of just not handling errors Doesn't go offer the simplest way of all to "just not handle errors"? Just ignore
by Buttons840 2y ago
> If you're given an easy way out, a simpler way of just not handling errors
Doesn't go offer the simplest way of all to "just not handle errors"? Just ignore them. It is an option. You can ignore them on purpose, you can ignore them by mistake, but you can always simply ignore them.
- ncruces 2y agoYeah, sure. But ignoring by mistake gets caught by linters, in practice. And then doing it on purpose is almost as noisy as bubbling it, and sure to raise an eyebrow in code review. My experience is with exceptions in Java/C#, Go errors, and C++ absl::StatusOr. In theory, I'd favor checked exceptions. In practice, I find that I'm always running away from polluting the happy path and coming up with contrived flow when I want to handle/decorate/whatever some errors but not others, and that giving types to checked exceptions becomes a class hierarchy thing that I've also grown to dislike. Both Go and C++/Abseil are indifferent if noisy to me (and C++ annoys me for plenty other reasons). Maybe elsewhere I'd find options better. Maybe.
- wruza 2y agoIsn’t the reason by chance how try-catch works lexically? I find that as another overlooked billion dollar mistake. It’s not that a happy path gets a crack in it, but the absolute monstrosity of a catch ceremony together with a scope torn between two blocks. “try {} catch {} finally {}” should be “[try] { catch {} finally {} }” absolutely everywhere.
- closeparen 2y agoIn practice I want the error propagated to the caller 95% of the time and swallowed 5% of the time. The problem is Go makes me explicitly spell out (and write a unit test case for!) the behavior I almost always want, while the rarely-desired behavior is default.