You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Attach existing frames from an error to a new error without wrapping #59
Errors are not always wrapped where the underlying cause is available via Unwrap -- this is common to avoid implementation detail leakages across API boundaries, to avoid callers depending on specific internal errors via errors.Is or errors.As.
However, this also loses any traces from the underlying errors, and traces aren't intended for APIs but debuggability. This is pretty common when Errorf is used with %v instead of %w. Ideally, we'd have some way to maintain the trace in these cases.
err:= [...]
if errors.Is(err, fs.ErrNotExist) {
returnWithTrace(err).Wrap(errUserNotFound)
}
From an API perspective, we should avoid an API that takes 2 error arguments where one's used for the underlying trace, and the other is the returned error, as it's too easy to mixup the arguments.
If we do something like this, we'll may want to define a cross-repo interface contract for extracting trace information (similar to pkg/errors' interface{ Stacktrace() errors.StackTrace }) from an error.
If we do something like this, we'll may want to define a cross-repo interface contract for extracting trace information (similar to pkg/errors' interface{ Stacktrace() errors.StackTrace }) from an error.
Activity
abhinav commentedon Nov 29, 2023
If we do something like this, we'll may want to define a cross-repo interface contract for extracting trace information (similar to pkg/errors'
interface{ Stacktrace() errors.StackTrace }) from an error.cbandy commentedon Jan 29, 2025
Perhaps addressed by eaa936c.