Ensure error objects are propagated without modification#1920
Ensure error objects are propagated without modification#1920aearly merged 6 commits intocaolan:masterfrom
Conversation
aearly
left a comment
There was a problem hiding this comment.
Can we keep the old behavior as well? I'm sure there are cases where people are throwing error-like objects that aren't actual Errors.
Co-authored-by: Alex Early <alexander.early@gmail.com>
|
@aearly done! I agree it's best to preserve compatibility with things that users may have been doing. |
|
Finally ran the CI pipeline, and noticed a lint error. Apparently |
|
@aearly done! Could you approve the CI workflow again? That said, I think the following line might have to change to Line 5 in 8610499 If you'd like to avoid that, I can rewrite this test to use a plain |
|
Hi, any maintainer can approve this? I'm really interested. We're using external libraries that generate errors without message field (they have errorMessages, ...) and then we get a String that says For us it's very urgent. Thanks a lot. |
|
Can you rebase again? |
|
@aearly sorry for not providing more precise instructions: the key {
"env": {
"browser": true,
"node": true,
"es2021": true
},Let me know if you'd like me to open a PR with that or incorporate it into this PR, I'd be more than happy to do so. |
|
Yes, at this point you're better off adding it to your PR. |
|
Published in v3.2.5 |
|
Many thanks for the quick release! |
|
Many thanks, great work! |
|
Hi, @nwalters512. I don't know why but if you check main branch the problem is still in there. Was the merge correct? |
|
@xescuder I'd recommend opening a new issue instead of continuing conversation on this merged PR. When you open one, can you be more specific with the problem you're seeing, and maybe provide a failing test? |
|
I've opened a new one. Many thanks. |
This PR specifically addresses the case of an
AggregateErrorbeing thrown, though it'll also handle the case of anyErrorobject with an emptymessage.When an
AggregateErroris constructed with only a single argument, itsmessageproperty is the empty string. This means that theerr.messagecheck fails, and theAggregateErroris passed to theErrorconstructor, losing information about it.I believe the
instanceof Errorcheck is most robust here, though it would be a change in behavior if someone was relying on being able to throw something like{ message: 'foo' }, i.e., something that's not actually anErrorinstance. An alternative would be to check for the presence oferr.errors, which would specifically handle the case oferrbeing anAggregateError.I wrote my test such that it doesn't rely on the
AggregateErrorglobal, which isn't available in some of the versions of Node that this repo is tested against. Instead, it checks that anErrorwith an empty message is propagated back to the caller without being wrapped in another instance ofError.