Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
assert: wrap original err on ifError fail#12820
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
Uh oh!
There was an error while loading. Please reload this page.
Conversation
refack commented May 4, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
refack commented May 4, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
|
Trott commented May 4, 2017
It might be the smallest semver-major ever, but I would still say semver-major. Imagine the impact on someone reading the stack traces if they run the same test on different versions of Node.js (which is what someone might do if they suspect they are triggering a bug in Node.js itself). If |
addaleax commented May 4, 2017
Is this a good idea, though? I think I would usually be more interested in the original stack trace (and apart from that, I think that this won’t work if somebody accessed |
joyeecheung left a comment
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.
We should add a test for this..
jasnell commented May 4, 2017
I'm not sure this is a good change to make. The errors are created elsewhere and passed here. Changing the stack trace would definitely be a breaking change (even if a mild one). I don't think this is behavior anyone would expect. |
refack commented May 4, 2017
One could argue that if you want the original stack, just throw it. If you use assert, you want to knwo which asset failed... |
cjihrig commented May 4, 2017
I think we should either throw the existing error, as is, or throw a new assertion error. This hybrid seems confusing. |
refack commented May 4, 2017
Bingo! |
refack commented May 4, 2017
Changed to wrapping the original |
ifError failjasnell commented May 4, 2017
Wrapping in the AssertionError works. We will definitely want to run some CITGM tests on this tho |
refack commented May 4, 2017
refack commented May 26, 2017
lib/assert.js Outdated
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.
message isn't used.
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.
Ack.
Forgot to carry it over into the last commit.
refack commented May 27, 2017
refack commented May 27, 2017 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
refack commented Jun 2, 2017
Ping @nodejs/testing |
refack commented Jun 9, 2017
I now kinda hate the current 1307parallel/test-util-callbackifyduration_ms0.89severityfailstack->assert.js:586assert.ifError=functionifError(err){if(err)throwerr;};^function(){context.actual++;returnfn.apply(this,arguments);} |
| Throws an `AssertionError` if `value` is truthy. This is useful when testing the | ||
| `error`argument in callbacks. If the `message` parameter is undefined, a | ||
| default error message is assigned, and `value` is be appended to it. |
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 feel this is somewhat contradicting each other. If it should be used in callbacks, there should always either be an error or the result but never both at the same time.
| common.expectsError({ | ||
| code: 'ERR_ASSERTION', | ||
| type: a.AssertionError, | ||
| message: /^Error:test_error_slug$/m |
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 am not sure how this is any different from the test above. I actually would expect this test to fail because I would have expected it to be wrapped in the ifError failed part.
| assert.ifError=functionifError(err){if(err)throwerr;}; | ||
| assert.ifError=functionifError(err,message){ | ||
| if(!err)return; | ||
| message=message||`ifError failed. Original error:\n${err}`; |
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.
Hm, is ifError really failing here? Maybe smth. like ifError encountered unexpected error: ... might be more intuitive?
BridgeAR commented Sep 20, 2017
Ping @refack |
BridgeAR commented Oct 2, 2017
I am closing this due to the long inactivity. @refack please reopen if you would like to pursue this further. |
For
assert.ifErrorfails, wrap the original err in a new AssertionErrorInspiration: #12803 (comment)
/cc @nodejs/testing
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
test, assert