The problem with ? is that it is not handling the error. It gives you a one-character mechanism for not handling the error. This is a regression from Go, from t

The problem with ? is that it is not handling the error. It gives you a one-character mechanism for not handling the error. This is a regression from Go, from the point of view of Go's design philosophy, not an advantage. It's one of the major things that has killed error handling proposals... anything that makes "if err != nil { return err }" easier is a bad thing. The minimal error handling code in Go is really: if err != nil { return fmt.Errorf("can't do thing thing I'm trying to do: %w", err) } That is actually the code we want to be made easier. "if err != nil { return err }" in my code is actually a specific claim that for error-handling purposes this function is conceptually part of the function that is calling it and it has just been factored out for other reasons.