3 ms·
> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. I'm not sure I follow this talk about "short cuts.". Exception
by KirinDave 7y ago
> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things.
I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open.
> Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog.
I'm used to languages where this generally isn't the case, but sure. Why twist the knife in the wound though?
> Glossing over error handling in golang can feel bad exactly when it should.
When you capture but fail to check an errval and an untraceable default value starts rattling around inside your code causing unexpected behavior? It's like an NPE but worse because it won't immediately trap. It's more like a double free.
- schrodinger 7y agogo vet catches that scenario and won’t pass CI. You have to explicitly decide to ignore it by using an underscore for the err value and then you get just what you asked for.
- KirinDave 7y agoSure, but it doesn't catch the case where you have multiple error variables in scope and you refer to the wrong one in one place but not the other or if you reuse an error. I've seen that happen more than a few times. Some of it in new production code.
- apta 7y agofmt.Println says otherwise. That and it's possible to overwrite previous error variables, something that is not possible with exceptions.