If we are trying to expose two "levels" of errors, one being warning
and another error, it is simpler to just expose a custom type Warning
to replicate the warning level of errors, and all other errors are
just errors.
Co-authored-by: Robert Lin <robert@bobheadxi.dev>
Co-authored-by: Alex Ostrikov <alex.ostrikov@sourcegraph.com>
Introducing custom error types can be tricky - I realized there's no code-level assertions or docs on Is and As implementations, so this PR introduces some interfaces to guide implementers. We write them ourselves because the standard library does not provide them, and it allows us to include docstrings better.
Wholesale migration away from go-multierror into a custom multierror implementation that is fully compatible with cockroachdb/errors, prints all errors, can be introspected with Is, As, and friends, and more. The new MultiError type is only available as an interface.
Co-authored-by: Camden Cheek <camden@ccheek.com>
This adds a couple of small helpers to make working with errors.Ignore a
little easier. Now, if you just want to ignore a certain error type,
instead of creating a function for it, you can just do something like
```
err = errors.Ignore(err, errors.IsPred(context.Canceled))
```
This adds the new helper function `Ignore` to our `errors` package. This
allows us to ignore errors based on a given predicate function in a way
that takes into account aggregated errors in MultiError. It recursively
unwraps to multierrors an filters out all child errors that match the
predicate.
