The pattern itself as written above is rather useless. What you end up with is a call 3 libraries deep that returns nothing but "EOF", and you have no idea what happened. In practice, you should really wrap every error return in a message and/or with a callstack. If the shortcut method can a) accomplish that, and b) avoid everything being nested, like try/except tends to do, I think I'd be more interested in the concept.
$variable1 := try $function_call_which_returns_two_values except $variable2: $expression_which_has_error_type
$variable1, $variable2 := $function_call_which_returns_two_values
if $variable2 != nil {
return ($zero_values_for_other_return_types, )* $expression_which_has_error_type
}Don't forget to check if someone else already had the same idea: https://seankhliao.com/blog/12020-11-23-go-error-handling-pr...
_, file, line, _ := runtime.Caller(2)
locTxt := fmt.Sprintf(" (at %s:%d)", filepath.Base(file), line)
But if you make the short syntax do something like this, it's gonna get used for hundreds of library's equivalents of `Atoi` or `ParseQuery`. I don't need line annotations on my `http.ResponseWriter#Write` timeouts, they're slow enough already.
(And if you are going to do it - really, just attach the whole stack trace then and there, it will probably be faster.)
Errors reach end users, and they cannot read stack traces.
Every shortcut makes for bad errors, bad troubleshooting and unhappy users.
Errors document code (you literally write, in English, what you were trying to do but failed, at each level of your program.)
Errors report to the user the clear intent that failed and why.
Errors are a huge differentiator in quality. There is no shortcut to quality.
In general, users don't care about errors or stack traces. They don't want errors of any kind. As a developer I want users reporting errors, which can include a dense stack trace, so I can get the error and an explanation of what they were doing when the error happened. I'm more for making my life easier than worrying about what a user sees.