4 ms·
the idea that error handling "pollutes" code is a misunderstanding which go addresses the "sad path" of error handling is equally as important as the "happy pa
by preseinger 3y ago
the idea that error handling "pollutes" code is a misunderstanding which go addresses
the "sad path" of error handling is equally as important as the "happy path"
- andrewjf 3y agoThen it would seem that it's required for the compiler to make sure you're consuming the return values (happy and sad) correctly by having the compiler enforce access to them, which go completely punts.
- za3faran 3y agoHow does it address it? By making it painstakingly verbose (not to mention error prone) to deal with errors? Not referring to you personally, but I've heard that sentiment several times now, and I have not seen anything to back it up (as with several other golang claims).
- lanstin 3y agowith robust and potentially high volume code, the most important feature is good behavior in failure domains. disk full, do you abort or continue once the cron job frees some space; cant alloc memory, do you abort or return a static 503 page? bad contents in some file, do you exit or log the error and carry on? does a bad pyc file generate a good error message or crash python. this robustness is the famed second 90% of the project. normal go looks a cerain way when it is handling these errors.
- za3faran 3y agoNothing you wrote is specific to golang's error handling though, and in actuality, ends up being more brittle because it is possible to miss handling such errors. At least an exception would bubble up instead of keeping the program running in an undefined state.
- preseinger 3y agoit is my very clear experience that rust programs are more brittle than go programs, precisely because rust makes it possible (even encourages) error "bubbling" via `?` in practice, go code bases that are subject to even minimal code review have basically no ignored errors
- lanstin 3y agoyeah my linters won't allow it. and bubbling up is exactly what you dont want for robust code. the UX is different for a failure on rereading a config file when you already have a good config vs. on startup. go code tends to be robust because the authors of the code and the community are the sort that worry about each err value, like Linux and like Python and like C itself.
- preseinger 3y agogiven a function fn that can fail, it will return a result and an error e.g. result, error = fn(...) calling this function should yield to the caller two possibilities, somehow: a success value _or_ a failure error the important thing is that in both cases, the control flow is visible in the source code as written result, error = fn(...) if there was an error, ... if it was successful, ... when an expression fails, you want to see the consequence in-line the success path and the failure path are equally important
- andrewjf 3y agoYeah, but you're still relying on the programmer to do it correctly which is nothing but false hope.
- preseinger 3y agono, it isn't
- za3faran 3y agoNothing is preventing the code from returning both at the same time. I've seen code (including in the standard library) that returns both an error and a return value. In a language with disjoint unions, such cases would be encoded properly.
- preseinger 3y agoconvention prevents it and in the case where returning both is OK, then documentation makes that clear this is not difficult
- aniforprez 3y agoConvention in no way prevents anything. Convention is simply that. People are free to not follow convention when nothing is enforcing it. You frequently see juniors, who may be brand new to the language, making mistakes with conventions. If I'm supposed to depend on the vagaries of some accepted standard that is only documented in text then it is less than useless in the real world
- deleted 3y ago[deleted]