4 ms·
You are right. I think what I don't like is that using this operator stops you being able to use the error as a value in the given context. I would rather alway
by liampulles 3y ago
You are right. I think what I don't like is that using this operator stops you being able to use the error as a value in the given context. I would rather always have the if block there, screaming it me, ready to be addressed. But certainly YMMV.
- deagle50 3y agoI think there's an easy solution to this, would love to know if I'm off track: postfix `catch` optionally captures the last value in the return tuple. Instead of value, err := foo(); if err != nil { // handle err }; you get value := foo() catch err { // handle err }
- otteromkram 3y agoWe have: if value, err := foo(); err { // do something with err. } else { // do something with value. }
- deagle50 3y ago"else" for the happy path is part of the problem.
- neilwilson 3y agoGenerally in Go the error path is part of the if, which usually returns from the function. Then the 'happy path' is just the rest of the function. If you end up with complexity at this point then it is time to refactor into several functions so the 'happy path' follows the standard idiom. Consider it a Go code smell.
- deagle50 3y ago> Then the 'happy path' is just the rest of the function. Right, and that's why it's bad.
- skybrian 3y agoSeems like the old and new syntax would still be there and the rewrite from one to the other is easy. Actually, maybe the IDE could (optionally) display it this way, so it’s not even a rewrite. The downside would be possible confusion when using another tool (like doing a diff).
- josephcsible 3y ago> I think what I don't like is that using this operator stops you being able to use the error as a value in the given context. Nobody would be making you use the operator all the time. In the rare cases when you need to do that, just don't use it.