4 ms·
please don't do this it obfuscates the control flow, specifically the value that is actually returned early returns on errors are good, not bad edit you want
by preseinger 3y ago
please don't do this
it obfuscates the control flow, specifically the value that is actually returned
early returns on errors are good, not bad
edit you want
func foo() error {
x, err := bar()
if err != nil {
return fmt.Errorf("bar: %w", err)
}
if err := baz(x); err != nil {
return fmt.Errorf("baz: %w", err)
}
if err := bat(); err != nil {
return fmt.Errorf("bat: %w", err)
}
return nil
}
- meling 3y agoYes, I absolutely agree with this. I think there is great value in returning early on error; think of them as guards checking that you have the values you need for the next logic step. In the original version you may have to read the whole function to understand why it failed.
- erik_seaberg 3y agoI’m all for generating that. I don’t want it in source where rereading it wastes expensive developers’ time and mistakes become possible.
- meling 3y agoCopilot is pretty good at recognizing and generating the error check ; it will even propose error messages for you. Clearly you may want to change it to your specific case. So I don’t think dev time will be significantly slower. My experience has been positive. I think the go plugin also has some helpers for this pattern, but I don’t recall exactly how they work.
- deleted 3y ago[deleted]
- preseinger 3y agonope error handling (as expressed here) is equivalent in priority to core business logic it absolutely belongs in source, because it is important for developers to see
- deleted 3y ago[deleted]