4 ms·
An improvement, really? It seems to me that it reinforces a bad pattern (returning an error directly without annotation) and will make return analysis of functi
by sagichmal 7y ago
An improvement, really? It seems to me that it reinforces a bad pattern (returning an error directly without annotation) and will make return analysis of functions in code review a lot harder. For what, to reduce typing? Doesn't strike me as a good tradeoff, and certainly feels at odds with Go's principles so far.
- butterisgood 7y agoI'm not sure I'm getting what you're saying. Try can only be used in functions that use error types as the last returned type. The compiler should be rejecting uses outside of that. So why is this any harder than thinking about "go" or "defer"?
- sagichmal 7y agoCurrently the only way out of a function is via the `return` keyword, or, exceptionally, panic. Those are easy to spot and easy to understand. With try, especially if it's nested in a complex statement e.g. fmt.Fprintf(os.Stdout, "%s: %d\n", try(getID()), try(getCount())) a function may return in surprising places.
- qtplatypus 7y agoI'm not sure that they are easy to spot. fmt.Fprintf(os.Stdout, "%s: %d\n", getID(), getCount()) Could have hidden panics in it and you would never know.
- sagichmal 7y agoYes, but panics are exceptional, and not something you need to worry about when doing a normal code review. Try would be commonplace.