proposal: spec: new builtin: handle

[jimmyfrasche]

What

handle must be deferred and only in a function whose last return value is type error. For brevity, I'll refer to this value as "the error" of the function.

handle takes an argument of type assignable to func(error) error. For brevity, I'll refer to this argument as an "error transformer".

If the error is nil, the error transformer is not called. If the error is not nil, the error transformer is called and its result replaces the error. Essentially:

if err != nil {
  err = transform(err)
}

Why?

This allows error handling routines to be written as library code. For example

func wrap(msg string) func(error) error {
  msg += ": %w"
  return func(err error) error {
    return fmt.Errorf(msg, err)
  }
}

which can be used like

defer handle(wrap("additional context"))

How?

This can be done via a macro expansion like mechanism in the compiler.

Given

func example() error {
  defer handle(wrap("oops"))
  //...
}

the compiler can treat it as if the code was

func example() (the_error error) {
  defer handle_impl(&the_error, wrap("oops"))
  //...
}
func handle_impl(err *error, f func(error) error) {
  if *err != nil {
    *err = f(*err)
  }
}

Alternatives

This could just be a regular function like:

package errors
func Handle(err *error, f func(error) error) { //...

That has two downsides:

1. the invocation is even longer
2. it's up to the user to pass the correct error which requires naming the return when otherwise unnecessary and making sure that name doesn't get shadowed.

A builtin obviates these, making it easier to use and thus more likely to be used.

This could be a keyword like

handle func(err error) error {
  return fmt.Errorf("oops: %w", err)
}

which is obviously much better but not backwards compatible.

A func returnedError() *error builtin that returns a pointer to the error of the deferring function. This is more powerful. You could use it to write handle and other things. It's a bit too magical and harder to use.

[gabyhelp]

Related Issues and Documentation

• proposal: Go 2: error handling: try statement with handler #56165 (closed)
• proposal: spec: check / handle with extra arguments #68720
• proposal: Go 2: Error handling that is compact and composeable #55026 (closed)
• Proposal: A built-in Go error check function, "try" #32437 (closed)
• proposal: errors: configurable Handle(error) function #33162 (closed)
• proposal: errors/errd: helper package for deferred error handlers #32676 (closed)
• Proposal: Go2: Drying up Error Handling in Go #36284 (closed)
• proposal: Go 2: error handling with handle keyword and optional return of error type #54677 (closed)
• proposal: Go 2: error handling with magic .handleErr() method #56126 (closed)
• Proposal: scoped error handling for named errors using `with .. handle err ...` #32795 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @jba for experience with doing this explicitly in pkgsite code.

[jba]

I use the explicit function in all my code now. I use this function:

// Wrap wraps *errp with the given formatted message if *errp is not nil.                                                                    
func Wrap(errp *error, format string, args ...any) {                                                                                         
        if *errp != nil {                                                                                                                    
                *errp = fmt.Errorf("%s: %w", fmt.Sprintf(format, args...), *errp)                                                            
        }                                                                                                                                    
} 

and call it like this:

func Frob(ctx context.Context, n int) (err error) {
    defer Wrap(&err, "Frob(ctx, %d)", n)
    ...
}

I don't find that to be a signficant burden, because I only use it for "important" functions. That seems to be about 10% of all functions, based on the pkgsite code (actual numbers: 2,292 functions, 263 calls to Wrap). And maybe a quarter of those functions already need named return types for documentation.

I also very rarely need to transform an error, just to add some context to get an approximate call trace.

So I don't think adding a built-in function is worth it.

[jimmyfrasche]

@jba your example could be added to fmt like

defer handle(fmt.Wrapf("Frob(ctx, %d)", n))

That's probably what 80%-90% of the uses of handle would be in practice. (That's not to say that handle isn't useful in other cases just that most of the time that's the only handling anyone needs!)

The next most common case would probably be logging like:

defer handle(logError)

Note that this is reacting to the error not transforming it but it can still be written as a transformer:

func logError(err error) error {
  doTheLogging(err) // reaction
  return err // identity transform
}

As errors are just values so are error transformers just functions.

We could just add functions to fmt and slog that take a *error but those would be less useful without handle since they require more ceremony to use and specifically one that people are wary to undertake as shadowing err can cause issues. For logging sometimes you just want to drop a logging statement in temporarily. That's trivial with handle but less so if you have to also change the function signature.

One thing I've run into a lot of times is that I'm working with a lot of io and I want to return on an error but I want to return nil on io.EOF and I need to do that in a lot of places. With this proposal that would just be

defer handle(func(err error) error {
  if err == io.EOF {
    return nil
  }
  return err
})

and even shorter with #21498:

defer handle(err => {
  if err == io.EOF {
    return nil
  }
  return err
})

I've written that using defer but most of the time it's too much bother and I just add the if err == io.EOF multiple times. Sometimes I'll write the real code in an unexported func and have a wrapper like

func Real() error {
  err := realImpl()
  if err == io.EOF {
    err = nil
  }
  return err
}

because it's less bother than dealing with all the stuff handle() takes care of. And with handle(), I could even write it once in an unexported function and use it in multiple functions in the same package.

This goes for anything you'd want to do the same thing in multiple error paths but that I've experienced most often in this one case.

It's true that handle()'s not doing much but it is reducing friction enough to make it simple to add some bulk error handling to a function, even if most of the time it'll just be logs or wrappers. Maybe you'd use it more often and in less important functions if it were simpler to do.

[x0wllaar]

I think that a more generic func returned[T any]() []**T, that, in a deferred function, returns a slice/array of pointers to pointers to all of the returned values of the deferred function will be magical, but extremely powerful for a lot of use cases.

It could be used to implement handle():

func Handle(transformer func (error) error){
    retVals := returned()
    retErr := **(retVals[len(retVals) - 1]).(error)
    if retErr == nil {
        return
    }
    newErr := transformer(retErr)
    *retVals[len(retVals) - 1] = &newErr
}

[jimmyfrasche]

That would require many changes to the language before you could represent and use the result. You could narrow that to something that returns a *error that points to the last error return, as noted in the initial post.

[x0wllaar]

I've modified my original comment. What other changes to the language will be needed compared to just returning *error?

[jimmyfrasche]

You would need to define what makes all of those lines of code legal. For example, you cannot have a slice where each value is a different type. That is a very complicated thing and not on topic for this issue.

[ianlancetaylor]

Thanks for the helpful proposal.

This is an idiom that some code uses but it is not particularly common. As both @jba and the original proposal point out, we can already do this, albeit more verbosely than this proposal.

The emoji voting is not strongly in favor.

Since it's not common and there is a way to do it, the benefit of this isn't worth the cost of a language change.

Therefore, this is a likely decline. Leaving open for four weeks for further comments.