This repository has been archived by the owner on Aug 30, 2023. It is now read-only.
Only use the cause with a stack trace in GetOrNewStacktrace #167
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following from #155, I realized that always passing in pkg/error's cause into
GetOrNewStacktrace
doesn't always work. This PR modifies the behaviour of this function so that it gives us the expected stack trace.For context, the pkg/errors package allows you to create brand new errors using
errors.New
anderrors.Errorf
which has a stack trace and does not wrap anything. It also allows you to wrap other errors usingerrors.Wrap
,Wrapf
, andWithStack
which returns a new error with a stack trace at the pointWrap
etc was called, and has the original error as the cause. So if you are using pkg/error in you application, then whenraven.CaptureError(err)
is called, you end up in one of the following situations:To provide the most context to the viewer of the error on Sentry, you would want to include the stack trace information as close to the original error as possible. For the scenarios above you want the stack trace at the point where:
The issue that this PR addresses is that naively using
errors.Cause(err)
will return the original error which, in the case of (2), won't always contain the stack trace that we want. Instead I added a new private functioncauseWithStacktrace
which finds the innermost error that does contain a stack trace. In the case (1) this returns the original error, in the case (2) this returns the first wrapped error, and in the case (3) this returns nil (since no layers contain a stack trace).CaptureError
andCaptureErrorAndWait
now passes the error it receives intoGetOrNewStacktrace
which callscauseWithStacktrace
. This PR also includes some go fmt changes and lint fixes.