-
Notifications
You must be signed in to change notification settings - Fork 33
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
Add info about cause
explicitly always being undefined
#124
Conversation
It aims for readable output rather than verbose completeness |
I think types are likely better be lenient instead. |
I don't understand this change. |
@mcollina Without this change accessing |
@voxpelli do you agree with this change? |
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.
I generally agree with it, yeah, I do would prefer the cause?: never
instead though
@KATT could you make it to be |
Co-authored-by: Pelle Wessman <pelle@kodfabrik.se>
Apologies about the delay - GitHub notifications are 💀 , I've updated it now |
Summary
Adds info that
cause
is always undefined.Motivation
[string]: any
and interpreted this as.cause
being supposed to be set.error.cause
? #123.cause
Errors, rely on message + stack summary instead #110Further comments
I am not sure if I agree with the decision to hide it, the original issue (#94), seemed to want explicit handling of
.cause
and not to hide it. It caught me by surprise.