proposal: all: unify context and return err idioms for error handling

[myaaaaaaaaa]

Proposal Details

Go is capable of achieving concise and elegant error handling today, without the need for any language changes.

The following code is the archetypal CopyFile() example, rewritten in terms of a unified context and return err pattern:

func CopyFile(ctx *context, src, dst string) {
	if ctx.Err() != nil {
		return
	}

	r := os.Open(ctx, src)
	defer r.Close(ctx) // must be robust to nil pointers
	w := os.Create(ctx, dst)

	if ctx.Err() != nil {
		// no need for fmt.Errorf("...: %v", ..., err)
		ctx.Push(fmt.Errorf("copy %s %s", src, dst))
		return
	}

	io.Copy(ctx, w, r)
	w.Close(ctx) // must close even if ctx.Err() != nil

	// a vet error can catch any accidental returns without checking ctx.Err()

	if ctx.Err() != nil {
		os.Remove(new(context), dst)
		ctx.Push(fmt.Errorf("copy %s %s", src, dst))
	}
}

Given that a v2 of the standard library is in the works, this is probably the best time to consider an API overhaul like this.

On the other hand, func(...) (T,error) may be too ingrained into Go culture at this point for a change like this.

[earthboundkid]

This feels like reinventing C's errno system.

Conceptually, you can split up functions into:

• Pure functions, which can't fail
• Functions which can fail but don't do syscalls and aren't time sensitive (e.g. converting a string to an int)
• Functions which do syscalls and/or are time sensitive and therefore can fail

I appreciate then that once context is involved, you always also need errors, but I don't think obscuring the return type helps. These are different kinds of functions, they should have different kinds of signatures.

If I were making a new language, I would use goroutine safe dynamic package variables instead of context and result types instead of error return tuples, but it's probably too late to change Go in either of those ways at this point, and it would be more than you could bolt on for a new standard library package.

[ianlancetaylor]

I'm not clear on what the proposal is. You are adding a Push method to context.Context? What are the semantics?

As you say, we could only make such a change in a context/v2 package.

[doggedOwl]

context package is already handling too many reponsibilites and it's polluting every function. this will make it impossible to write any function without the god-like context

[qiulaidongfeng]

A major problem with go error handling is repeat code such as：

if err!=nil{
    return nil,err
}

The proposal does not solve that.

The API with and without a receive context has swollen the number of standard library apis, and if try func(...) (T,error) and func(context,...) (T) Two different forms, adding API is a lot of work, not worth the loss.

[gabyhelp]

Related Issues and Documentation

• proposal: Go 2: Error handling check/with #49091 (closed)
• proposal: Go 2: Error handling with try-with-resources #29120 (closed)
• proposal: Go 2: Error handling that is compact and composeable #55026 (closed)
• proposal: Go 2: simplify error handling with expect #32804 (closed)
• proposal: Go 2: block scoped error handling #33161 (closed)
• proposal: Go 2: error handling: try statement with handler #56165 (closed)
• Proposal: `on...return` for error handling #48855 (closed)
• proposal: Go 2: local-only throw-catch error handling #48896 (closed)
• Proposal: Use Context for the proposed built-in Go error check function, "try" #32853 (closed)
• proposal: Alternate to try(): 1. Call func/closure from assignment and 2. break/continue/return more than one level. #32473 (closed)

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

[myaaaaaaaaa]

Closing due to unanimous disapproval (see emoji votes)