Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aka-rider opened this issue Feb 16, 2020 · 6 comments
Open

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

aka-rider opened this issue Feb 16, 2020 · 6 comments

Comments

@aka-rider
Copy link

@aka-rider aka-rider commented Feb 16, 2020

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
Copy link
Author

@aka-rider aka-rider commented Feb 16, 2020

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

#37228

@ianlancetaylor ianlancetaylor changed the title Proposal to add Temporary(error) bool function into errors package proposal: errors: add new function Temporary(error) bool Feb 17, 2020
@gopherbot gopherbot added this to the Proposal milestone Feb 17, 2020
@gopherbot gopherbot added the Proposal label Feb 17, 2020
@D1CED
Copy link

@D1CED D1CED commented Feb 17, 2020

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
Copy link
Author

@aka-rider aka-rider commented Feb 18, 2020

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
Copy link
Contributor

@rsc rsc commented Feb 26, 2020

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
Copy link
Author

@aka-rider aka-rider commented Feb 26, 2020

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
Copy link
Contributor

@rsc rsc commented Mar 11, 2020

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.

@rsc rsc moved this from Active to Hold in Proposals Mar 11, 2020
@rsc rsc added the Proposal-Hold label Mar 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.