proposal: errors: add new function Temporary(error) bool

[aka-rider]

Good day.

This is proposal to add the Temporary function into errors package. I tend to rewrite it over and over again in every project.

Possible implementation:

// Temporary returns true if it makes sense to retry the call that returned the error.
func Temporary(err error) bool {
	if err, ok := err.(interface{ Temporary() bool }); ok {
		return err.Temporary()
	}
	return false
}

Mainly, this function will be used in conjunction with the net package.
Nevertheless, I think Temporary function belongs to the erros package, in this case user code and other packages may follow the same convention.

The main reason for adding a new function into the go standard library is to promote the "Temporary" concept.
If there's no common mechanism to determine if operation can be retried then error handling becomes more intricate.
Also, I think the function is in line with the "errors are values."

[aka-rider]

I was not familiar with the Go Proposal Process and wrongly opened a merge request. I leave it here for tracking.

#37228

[D1CED]

I don't know if you are aware of the errors.As function introduced in Go 1.13. It does something very similar and integrates well with the Unwraper interface.

It would look like this:

func Temporary(err error) bool {
	var temporaryVar interface{ Temporary() bool }
	if errors.As(err, &temporaryVar) {
                return temporaryVar.Temporary()
        }
        return false
}

Edited: calling Temporary method. And now it looks similarly as yours.

[aka-rider]

Hi @D1CED

Your code does a different thing. It checks that it is possible to convert error to the interface with Temporary but the goal is to call Temporary function if it does exist.

[rsc]

There are semantic problems with Temporary that we have to work out first. It may be that we end up deprecating Temporary entirely. See #32463 for more discussion.

[aka-rider]

Hi @rsc

Thanks for the clarification.

I totally agree that Temporary and Timeout both need a clear semantic, and I think this comment captures the essence of it from the pure pragmatic point of view: errors are values, and I may not know (care) meaning and origins of the error while I have a ready recipe to treat the error programmatically.

Even if Temporary and Timeout emerged solely as a mechanism to handle Linux syscalls, there is a demand for them outside of the Go standard library.

The possible implementation can be a third-party package but such implementation:

• would be a horrible chain of if statements
• would not promote the mechanism across the go ecosystem (my main concern)

I also like the idea to have these mechanisms built into the standard go library because it shifts responsibility towards the library creators (more experienced go programmers). Even though the particular implementation of the theoretical Temporary() function may introduce some pitfalls, the end-users should be able to call it blindly.

[rsc]

This should probably be on hold until we figure out whether Temporary disappears entirely. But right now we are taking a bit of a hiatus from error handling.

[seankhliao]

Temporary was deprecated in #45729 , I think this can be declined?

[ianlancetaylor]

Moving back to Active to give people a chance to object, but in general this seems likely to be declined.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group