4 ms·
In distributed systems (i.e. what Go was designed for), 90% of your actual logic is dealing with errors of different shapes and colors. How you handle that is w
by slrz 10y ago
In distributed systems (i.e. what Go was designed for), 90% of your actual logic is dealing with errors of different shapes and colors. How you handle that is what makes the difference between a toy and a reliable system.
Code doesn't become easier to read/understand by just tucking away 90% of it (the hard/interesting parts at that, mind you).
- jjnoakes 10y agoDealing with errors should create noise in the code in proportion to the places where error handling needs to take action. If 90% of your code really is unique, specific action to error conditions, then by all means, this topic isn't for you. But if 90% of your code is "stop processing in this function, log the error, and pass it up the stack", then why not abstract that away and reduce the noise? (i.e. something like exceptions or monads or arrows or ...)
- stouset 10y agoYes, thank you. If you somehow have a problem domain where most of the errors you encounter can be gracefully (but uniquely) handled, then that's fantastic for you. But in virtually every golang example I've seen, you're just gift-wrapping the error with a little bit more context (or not) and returning it up the stack. In which case you've just replaced automatic, computer-executed exception handling with bespoke, artisanal, handcrafted exception handling for no gain and a hell of a lot of loss.