3 ms·
> In fact, Go doesn’t make you deal with your errors Your right, it does not. I will _ =: an error in a throw away script all the time. I see that in a code r
by zer00eyz 3y ago
> In fact, Go doesn’t make you deal with your errors
Your right, it does not. I will _ =: an error in a throw away script all the time.
I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
- strongly-typed 3y agoI'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug. [0]: https://github.com/semilin/genkey/commit/fafed6744555c5a81fd2c6f218091cc746150c05 https://github.com/semilin/genkey/commit/fafed6744555c5a81fd... EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
- randomdata 3y ago> The fact that this was a bug at all makes me fear for the rest of the code base. The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.
- nasretdinov 3y agoIs the wrong code in the new part of the diff or in the old one? Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh