-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: include .cause
stacks in the error stack traces
#4829
Conversation
This PR hasn't had any recent activity, and I'm labeling it |
Still relevant |
This PR looks good to me. We'd love for this to land. We had to implement some workarounds in the https://github.com/sequelize/sequelize test suites because our own error messages make heavy use of the |
This PR hasn't had any recent activity, and I'm labeling it |
Would still love to see this merged |
Same here |
This PR hasn't had any recent activity, and I'm labeling it |
Labeling someone's work as stale because you haven't had time to review is not great :/ |
@juergba would be great if you could take a look at this. Node 16 is the oldest still supported version of Node so there are no supported versions anymore that do not have Error.cause |
This PR hasn't had any recent activity, and I'm labeling it |
Still a lack of review, not this PR itself being stale |
Is this going to be merged? we want to start using the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 excited to see cause
support finally land!
We looked at this as a group, agreed with the general direction. Just a bit of edge case handling needed.
Requirements
Description of the Change
Appends the full error stack chain for errors with causes.
Alternate Designs
Prior to the Error cause standardization, there was
VError
which I did a PR for supporting some years ago #2381. That one as primarily closed because an aversion to supporting random module hooks, which this now being a standard changes.So I think this is now more a matter of:
Why should this be in core?
All current browsers supports this property and Node.js as well since
16.x
.See also eg:
pino
merging support for it: Serializeerr.cause
in a nice way when possible pinojs/pino-std-serializers#78Benefits
Error causes are a great way to enrich errors and to ensure that one can catch all relevant places across an async workflow. See also eg. this old Joyent article explaining how they uses VError.
Possible Drawbacks
Applicable issues
cause
property, else it would be a minor. So depends on whether the specific stack output is seen as an API that should be stable or whether it's simply a presentation detail.Fixes #2735.