func foo() error {
var err error
err = bar()
if err != nil {
return err
}
err = baz()
if err != nil {
return err
}
return nil
}
And the final "?" proposal doesn't actually deal with the errors. Part of the point of Go's error handling is to force us to deal with the errors. Endless "if err != nil {return err}" statements is kinda an antipattern in Go. Yes it's common, but I'm sure that's because we've been trained by exception handling to just pass the errors up.A better (but still not perfect) pattern is to wrap the errors:
if err != nil {
return fmt.Errorf("tried to foo the bar with parameter %s, failed with: %w", baz, err)
}
And obviously, an even better pattern is to actually deal with the error - retry after a delay? return a custom "abandon goroutine" error? Endlessly passing the errors up the stack until some function passes an incomprehensible error message to the user is what we're trying to get away from here.