This is absolutely idiomatic, with progressively increasing levels of opt-in expressivity. "If you want [additional] error abstractions, you just program them yourself" was clearly demonstrated: my "tree" of error-chaining was only one level deep (FunctionError), but that's a nit.
> "continue" doesn't recover from an error, obviously.
ErrTryAgain clearly carries semantic meaning that "continue" acts upon.
> Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major Go error handling warts. Since you (like everyone else) didn't create an error variable or type to capture any of the meaning of the error, what you've created is a by-design unrecoverable error, one where your only hope of responding in any way other than aborting the entire operation is to parse the string error message, which is something more than one Go program has had to do.
I demonstrated an alternative for situations when clients might want to parse and act on errors.
And in doing that, you demonstrated that the idiomatic default in Go error handling is unhandleable errors, the sort that forces programmers to pitifully parse strings to differentiate.
I kind of love Go. I'm a former professional C programmer and Go is now my default language. But I don't feel a need to kid people about things Go gets wrong.
This is absolutely idiomatic, with progressively increasing levels of opt-in expressivity. "If you want [additional] error abstractions, you just program them yourself" was clearly demonstrated: my "tree" of error-chaining was only one level deep (FunctionError), but that's a nit.
> "continue" doesn't recover from an error, obviously.
ErrTryAgain clearly carries semantic meaning that "continue" acts upon.
> Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major Go error handling warts. Since you (like everyone else) didn't create an error variable or type to capture any of the meaning of the error, what you've created is a by-design unrecoverable error, one where your only hope of responding in any way other than aborting the entire operation is to parse the string error message, which is something more than one Go program has had to do.
I demonstrated an alternative for situations when clients might want to parse and act on errors.