Structured errors are currently a wrapped error and an optional error code. We have a builder, NewStructuredError(error, string) that is used to wrap the provided error along with the provided error code.
In https://github.com/elastic/package-spec/pull/690#discussion_r1467861976 a discussion was raised on whether we should wrap structured errors in structured errors. In some cases we are doing NewStructuredError(errors.New(err.Error()), string), what loses infomation about err. We have to decide about what to do about this.
If we want to avoid wrapping structured errors, while keeping information about the wrapped errors, we can implement NewStructuredError as something like this:
// NewStructuredError creates a generic validation error by wrapping the given error. If the given error
// is already a StructuredError, the returned error wraps the error wrapped by the given error.
func NewStructuredError(err error, code string) *StructuredError {
if se, ok := err.(*StructuredError) {
result := *se
result.code = code
return &result
}
return &StructuredError{
err: err,
code: code,
}
}
And review the uses of NewStructuredError so we use it consistently.
Structured errors are currently a wrapped error and an optional error code. We have a builder,
NewStructuredError(error, string)
that is used to wrap the provided error along with the provided error code.In https://github.com/elastic/package-spec/pull/690#discussion_r1467861976 a discussion was raised on whether we should wrap structured errors in structured errors. In some cases we are doing
NewStructuredError(errors.New(err.Error()), string)
, what loses infomation abouterr
. We have to decide about what to do about this.If we want to avoid wrapping structured errors, while keeping information about the wrapped errors, we can implement
NewStructuredError
as something like this:And review the uses of
NewStructuredError
so we use it consistently.