3 ms·
I did some regex analysis on my codebase of over 37000 lines. In exactly 566 occurrences of "if err != nil", there were only 154 that just returned the error di
by assbuttbuttass 3y ago
I did some regex analysis on my codebase of over 37000 lines. In exactly 566 occurrences of "if err != nil", there were only 154 that just returned the error directly. The other instances are doing some form of wrapping to add more context to the error, or collecting errors from multiple operations, or wrapping the error with a status code, or a bunch of other things.
The problem with every error handling suggestion I've seen is that it only handles the one case
if err != nil {
return nil, err
}
But that's only the case 27% of the time! The other cases are harder, and require more thought anyway. Why optimize for a rare case that's already easy?
- deagle50 3y agoThanks for looking this up. I'm not just referring to blocs that just return the error, though even then your 154 occurrences lead to 462 lines of noise. Noise that could could be avoided with sugar like `?`. I'm referring to all the code blocks that start with `if err != nil {`. Wrapping and adding context could be done at the end of the previous function call and we wouldn't have to read boilerplate over and over.