3 ms·
The problem I have with Go's error handling is that it makes you choose: Either you write a function that can return errors or you write a function that can be
by fauigerzigerk 10y ago
The problem I have with Go's error handling is that it makes you choose: Either you write a function that can return errors or you write a function that can be used as part of a larger expression. It can never be both.
result := f() * g()
becomes
x, err := f()
if err != nil {
//handle f() err
}
y, err := g()
if err != nil {
//handle g() err
}
result := x * y
Even without exceptions I can imagine to have something like
result, err := f() * g()
if err != nil {
//handle err
}
Of course that raises a lot of other questions if functions can have side-effects (but possibly no more so than shortcut logical operators)
- mratzloff 10y agoYou must choose, but there's nothing stopping you from collecting errors in the background and creating a monad. Return a maybe value and expose a way to access the error.
- fauigerzigerk 10y agoWhat's stopping me from doing that more often than I do is that it's too much work. Collecting errors is just part of it. You also have to make sure nothing that has side effects gets called after the first one. Without language support this is tortuous and error prone.