4 ms·
The one item I'd really contend is where it says it "makes it easier to ... maintain over time". That might be true for smaller code bases (tracking down excep
by tankenmate 6y ago
The one item I'd really contend is where it says it "makes it easier to ... maintain over time".
That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, welcome to distributed systems (logically, physically or chronologically distributed)).
[EDIT] fixed thinko
- DoctorNick 6y agothank you for emulating the experience of debugging distributed systems
- knz42 6y agoThis was clarified in the conf talk [1] [2]: error returns should be used at API boundaries, and panic-driven handling only "within" a component. [1] https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s [2] https://docs.google.com/presentation/d/1WVu4O-ax7punUC2V_XgTA0VqZReToo1sNXA5IaHFqdE/edit https://docs.google.com/presentation/d/1WVu4O-ax7punUC2V_XgT...
- tankenmate 6y agoFor simplicities sake I just use error returns everywhere and then you have a consistent error handling abstraction (and one that scales to boot).
- trinovantes 6y agoThis is one of the reasons why I really like monorepos. Tracking down an opaque error from 2 network hops away is a nightmare compared to reading an exception in a call stack