Re:Go Error Handling Proposals
by kadoban on Tuesday June 08, 2021 @10:03PM
(#27443413)
Because when you return `foo, err` , your caller has to remember not to use the foo.
And when you're constructing your return values, often if you have an error, you won't have a real `foo` to give back, which raises the temptation to return a pointer-to-foo instead so you can give nil in that case.
But then your caller has to check for the nonsense case where there's no error but also a nil foo.
Usually what is meant is "I'll return a foo _or_ an error" but what go's type system encodes is "I'll give you a foo and maybe an error" or "I'll give you maybe a foo and maybe an error" depending on what choice you make.
And when you're constructing your return values, often if you have an error, you won't have a real `foo` to give back, which raises the temptation to return a pointer-to-foo instead so you can give nil in that case.
But then your caller has to check for the nonsense case where there's no error but also a nil foo.
Usually what is meant is "I'll return a foo _or_ an error" but what go's type system encodes is "I'll give you a foo and maybe an error" or "I'll give you maybe a foo and maybe an error" depending on what choice you make.