4 ms·
Named return parameters are unfortunate. Probably better to never use them unless you have to (like if you are "catching" a panic). Otherwise, I think you are n
by pkulak 13y ago
Named return parameters are unfortunate. Probably better to never use them unless you have to (like if you are "catching" a panic). Otherwise, I think you are nitpicking a bit.
- frou_dh 13y agoThat usage with recover would be to be able to set return parameters that might otherwise be returned as their zero values, correct?
- pkulak 13y agoExactly. You can't return from the outer function in a defer, but you do have access to named return values. It's a bit of a kludge.
- ihsw 13y agoWhat's wrong with named return parameters?
- RamiK 13y agohttp://golang.org/doc/effective_go.html#named-results http://golang.org/doc/effective_go.html#named-results It's far more convenient looking at the function deceleration and knowing what comes and goes instead of hunting for return statements.
- twotwotwo 13y agoI don't mind using named returns a lot--they can help to document, and sometimes they save you a declaration you were going to do in the method body anyway. There are times they can be redundant (Sum(ints) does not need its return value named), or make the code less clear, or they indicate that you're trying to work around having overcomplicated methods by documenting them--I'm not saying always use them. But I don't try to avoid them.