3 ms·
Hmmm so Go is getting monadic behaviors with "try" to hide error handling issues with examining every single one with "if". I think this is a rather large impr
by butterisgood 7y ago
Hmmm so Go is getting monadic behaviors with "try" to hide error handling issues with examining every single one with "if".
I think this is a rather large improvement to error handling. I need to read more about how it works with "go" and "defer" (it's all in there).
- millstone 7y agoIt looks like a big improvement but it's definitely not monadic. It's a hidden return.
- butterisgood 7y agoIf you sequence (>>=) a series of Maybe's in Haskell you have hidden returns as well. Since we're talking about the application of "bind" you could think of the "invisible semicolon" in Go as the same kind of bind between "try" statements in Go, and get very similar behaviors - conceptually. At least, that's how I think I've understood "try" to work. (pseudocode... ) f := try(open(...)) num_bytes := try(write_some_bytes(f, ...)) I hope my function bailed out early at "f := try(open(...))" because the line "num_bytes..." literally makes no sense at all if f hasn't been even declared "f :=" vs "f =". In the end, if I don't like it, I don't have to use it, but I still have to understand it if it's in the language and I'm reading other people's code.
- sagichmal 7y agoAn 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.