e3d608a866
In order to generate more accurate or informative error messages from the type checker, it can be helpful to interpret error messages in context. This is currently achieved in a number of ways: + Return a boolean value, and then reverse-engineer the error at the callsite (as in representable->representableConst). + Return a value causing the error (as in Checker.missingMethod), and add the error at the callsite. + Pass a "reason" string pointer to capture the error (as in Checker.assignableTo), and add the error at the callsite. + Pass a "context" string pointer, and use this when writing errors in the delegated method. In all cases, it is the responsibility of whatever code calls Checker.error* to set the operand mode to invalid. These methods are used as appropriate, depending on whether multiple errors are generated, whether additional context is needed, and whether the mere presence of an error needs to be interpreted at the callsite. However, this practice has some downsides: the plurality of error handling techniques can be a barrier to readability and composability. In this CL, we introduce Yet Another Pattern, with the hope that it can replace some or all of the existing techniques: factor out side-effect free functions that evaluate a single error, and add helpers for recording this error in the Checker. As a proof of concept this is done for Checker.representable and Checker.convertUntyped. If the general pattern does not seem appropriate for replacing some or all of the error-handling techniques listed above, we should revert to an established technique. Some internal error APIs are refactored to operate on an error, rather than a types.Error, with internal error metadata extracted using errors.As. This seemed to have negligible impact on performance, but we should be careful about actually wrapping errors: I expect that many users will expect err to be a types.Error. Change-Id: Ic5c6edcdc02768cd84e04638fad648934bcf3c17 Reviewed-on: https://go-review.googlesource.com/c/go/+/242082 Run-TryBot: Robert Findley <rfindley@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> |
||
|---|---|---|
| .github | ||
| api | ||
| doc | ||
| lib/time | ||
| misc | ||
| src | ||
| test | ||
| .gitattributes | ||
| .gitignore | ||
| AUTHORS | ||
| CONTRIBUTING.md | ||
| CONTRIBUTORS | ||
| favicon.ico | ||
| LICENSE | ||
| PATENTS | ||
| README.md | ||
| robots.txt | ||
| SECURITY.md | ||
The Go Programming Language
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
Gopher image by Renee French, licensed under Creative Commons 3.0 Attributions license.
Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.
Download and Install
Binary Distributions
Official binary distributions are available at https://golang.org/dl/.
After downloading a binary release, visit https://golang.org/doc/install or load doc/install.html in your web browser for installation instructions.
Install From Source
If a binary distribution is not available for your combination of operating system and architecture, visit https://golang.org/doc/install/source or load doc/install-source.html in your web browser for source installation instructions.
Contributing
Go is the work of thousands of contributors. We appreciate your help!
To contribute, please read the contribution guidelines: https://golang.org/doc/contribute.html
Note that the Go project uses the issue tracker for bug reports and proposals only. See https://golang.org/wiki/Questions for a list of places to ask questions about the Go language.