I didn’t handle those errors because I don’t know how to.
On its surface error handling looks simple. Just call errors.New or fmt.Errorf, right?
How do you keep track of the context of an error deep in your call stack? How about when multiple errors happen at the same time, such as properly handling
Since errors are values, these more difficult situations can be handled with code. Here are some packages to help handle your errors.
Monitors the rate of errors and then takes a defined action when the error rate is too high. A higher-than-normal error rate may indicate some larger problem such as the network problems or a full disk.
Use a stack to add context to errors as they are returned without losing the original error.
Add extensive context optimized for debugging to
- Error numbers that are
grepable in your source
- A message explaining what caused the
errorthis context is for
- Key/value pairs for adding additional context to the
All of this information is formatted when printed.
Add context to
- Override the message or add additional messages
- HTTP status codes
- key/value pairs for additional context
error(s) this context is for, as a hierarchy
Additionally, you can:
- control how much of the context is printed out (at the print site)
- easily check the error hierarchy to see if an
errormatches the one you are checking for (i.e.,
err == io.EOF, but for the entire hierachy)
Based on and inspired by github.com/go-errors/errors, github.com/go-errgo/errgo, and github.com/amattn/deeperror.
Create errors that marshal to JSON and XML with a Code (
int for e.g. HTTP status), Meta (
string), and Fields (
Combine multiple errors into a single
error. Check if one of those errors is the error you are looking for (e.g.,
err == io.EOF, but for the entire collection).
Enable debug or trace information per
error or globally. Debug adds the location the
error was created, Trace adds the stacktrace.
Provides ways to create, add context to, and inspect/diagnose
errors. Combines many orthogonal features into a single package.
Add a stacktrace to any
A slice of
errors in a single error. Seems to do everything that is needed for this use case.
Preserves the original error and its origin while adding contextual information for error reports and logs.
Formalizes the pattern of wrapping errors, checking if a specific error is wrapped, and extracting wrapped errors.
Represent a list of
errors as a single
error with a cutomizable format when the
errors are printed.
Use a fluent interface to add context to
- Key/Value Pairs suitable for structured logging
Add messages as context to an existing
error sentinels and checks for common situations (e.g., method not allowed).
error handling when dealing with
Add context to an error message with a set of key-value pairs.
Add context to
errors along the call stack:
- line number information
- error codes
Add context to
Use error templates to add identifiers, severity, categories, or other data to errors.
errors with pretty printing for your parsing/lexing/interpreting needs.
errors and determine if a specific
error falls into that class using error hierarchies. Attach additional data to an
error using arbitrary
error values. Track where an
error comes from using stack traces and track how an
error was handled using exit recording. Collect
errors together using ErrorGroup and its variants. Convert
errors with CatchPanic.
Add file, line, and stack information to
errors by wrapping them.
Combine one or more
errors into a single