New Error Constructors: code.Error(msg) and code.Errorf(msg, a...) #339
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Build Twirp Errors from the Code
The standard error constructor
twirp.NewError(twirp.ErrorCode, msg)
stutters and is a bit verbose.Since the code constants are already defined at the top level of the twirp package, they can be used to build all the error types. It is easier to read and consistent for all codes:
Errorf to format and wrap other errors
The signature
Errorf
is a well-known idiom in Go and could be used to format errors exactly as it would be expected:Wrapping errors with "%w" is specially useful to prefix internal errors. APIs that use middleware to report errors often need to unwrap those errors to know the originals, but having a prefix in front of them is useful for debugging. Example:
Existing constructors enhanced
Existing constructors still apply and are consistent with the new ones. An
Errorf
version of those constructors was also added for consistency.Usage Example
Let's see how the new constructors look like on an example endpoint implementation:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.