-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: Add generic fail package to standard library for error handling #58631
Comments
@gopherbot add error-handling |
For a pure library like this we would typically suggest that we try it out as an external package first and see what kind of adoption it gets. |
Have you seen @dsnet's try? https://pkg.go.dev/github.com/dsnet/try This seems very similar. |
@ianlancetaylor While I would normally agree with https://go.dev/doc/faq#x_in_std, seeing that error handling in Go is a hot topic, which has been looking for a solution for a decade, I am proposing we skip the step of the external package and get started with a design and then try it out in x/ as an experimental package. I don't really care about the name or the details of the implementation, the idea is to use existing language features including generics to solve the Go error handling problem in a standardized way. Seeing how we now are getting slog for structured logging, which was also long overdue, I think it would be a good idea to cut to the chase, so to speak. Especially because it looks like we will not add any new language features to Go for error handling. So I thought the standard library approach would be best then However I would also not object if this proposal were to be put on hold until there are a few similar packages like this. @carlmjohnson I looked at it and while it is similar, my example has the benefit that the both the check functionand the error handlers are returned as higher order functions and can be reused. And also that I choose for more readable function names. But one reason I made this proposal is for everyone to help out with the design. What I have is just something I cobbled together in a few hours. |
Error handling happens a lot and is required to be efficient almost every time. I don't believe, that generics spread over closures and panics with their stack unwinding is the best tool for the job. |
I think Ian is proposing that you don't skip that step. Something as important as this should be carefully evaluated within a single large project (or company) before it pretends to be a good solution for everyone. There's no need to involve the x/ repos. |
I have been trying out generics for error handling, and I found that it might be a good approach to consider, in stead of changing the language. Therefore I propose adding a new package to the standard library, named "fail", for now, which does such error handling, using fail.Check() and fail.Save() as the main API.
The interesting points about this approach are that error handlers can be defined and reused easily, that even the Check can be reused easily, though a combination of higher order functions, generics and panic/rescue, and that it is all very simple to use and to implement.
The weakest points are the need for Check2, Check3 ... functions for that return more results than just one and an error, although these are relatively rare in Go, that it requires named return values, and the fact that this does use panics behind the scenes, although this can also be seen as a benefit in a sense.
In a later stage then, if deemed necessary, some of these functions could be made built-in functions with the same semantics, but that can be considered after this proposal.
Below is a sketch of how this could work. It was tested only slightly, and probably needs to be improved a lot.
https://go.dev/play/p/jQRLjq-0pw0
The text was updated successfully, but these errors were encountered: