Documentation
¶
Overview ¶
The terror package implements typed, user friendly errors in go. The typed errors parallel and are compatible with HTTP errors. A typed error has two basic components: * A user friendly error message meant for viewing by an end-user. * The original underlying error, if any.
Note that terror is meant to augment, not replace, basic go errors. In particular, terror is not very useful when dealing with pure backend libraries or anyplace where all the errors would by necessity be 'ServerError' types. Rather, terror is meant to be used primarily at the boundary of user input and request handling where there's the possibility that the problem is something other than a programming bug or backend systems problem.
Another possible use case would be in an unrelable network environment where 'retries' would be a common occurance. In general, terror is useful when the caller might take different actions based on the error type and not so useful when all the caller can do is give up gracefully.
Implementations can thus easily support both communicating directly to the user while maintaining all the raw information one would want to capture in a log.
terror also supports easy debug logging by either calling 'EchoErrorLog' from your test file or setting the `DEBUG_TERROR` environment variable to any non-blank value.
Index ¶
- func EchoErrorLog()
- type Terror
- func BadRequestError(message string) Terror
- func ForbiddenError(message string) Terror
- func MethodNotAllowedError(message string) Terror
- func NotFoundError(message string) Terror
- func ServerError(message string, cause error) Terror
- func UnauthenticatedError(message string) Terror
- func UnprocessableEntityError(message string) Terror
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func EchoErrorLog ¶
func EchoErrorLog()
Types ¶
type Terror ¶
type Terror interface {
Error() string
Code() int
HasCause() bool
Cause() string
CauseError() error
}
Terror interface supporting immutable results.
func BadRequestError ¶
BadRequestError (400) indicates a malformed request. See [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1)
func ForbiddenError ¶
ForbiddenError (403) indicates a properly formed request by an authenticated with is none-the-less unauthorized. While `UnauthorizedError` would be the better name, this would conflict with the HTTP standards use of the term, so in this case we keep "forbidden" to avoid confusion. See [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4)
func MethodNotAllowedError ¶
MethodNotAllowedError (405) indicates a properly formed request that is understood by the server, but whose method is not allowed or not supported for the target resource. This is distinct from where a method is possible, but not allowed under current circumstances, in which case `UnauthorizedError`, `ForbiddenError`, or others may be appropriate. See [RFC7231](https://tools.ietf.org/html/rfc7231#section-6.5.5)
func NotFoundError ¶
NotFoundError (404) indicates a properly formed request for something which is not there. See [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5)
func ServerError ¶
ServerError (500) indicates an unexpected server side error. See [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1)
func UnauthenticatedError ¶
UnautthenticatedError (401) indicates a properly formed request that lacks required authentication. Note that the HTTP standards call this "Unauthorized", rather than "unauthenticated". We prefer the latter to maintain a clear distinction between authentication and authorization. Use `ForbiddenError` for unauthorized requests. See [RFC2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2)
func UnprocessableEntityError ¶
UnprocessableEntityError (422) indicates a properly formed request with semantically invalid content. See [RFC4918](https://tools.ietf.org/html/rfc4918#page-78)
Source Files