-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
test: wrap assert.fail when passed to callback #3453
Conversation
/cc @jasnell |
LGTM |
LGTM pending CI |
@@ -25,7 +25,7 @@ process.on('exit', function() { | |||
console.log('ok'); | |||
}); | |||
|
|||
// make sure that flush/write doesn't trigger an assert failure | |||
// make sure that flush/write doesn't trigger an common.failure |
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.
find/replace error in this 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.
fixed
LGTM pending CI Speaking of which: https://ci.nodejs.org/job/node-test-pull-request/547/ |
CI results breakdown: freebsd101-32 failure is a known flaky test that #3430 intends to fix. Three tests on ppcbe-fedora20 and one test on ppcle-ubuntu1404 (or did I put that backwards?) are all known fail-every-time tests on those platforms. (Probably should mark them as flaky for those platforms in win2008r2 vs2015 is build step explosion. win10 vs2015 is one test failure that was untouched by this PR and then a build step explosion. ubuntu1404-32 is a failure in a test untouched by this PR. In short: LGTM |
I don't have a specific concern with either this or #3378, but my thought regarding this particular pattern is that it is already in use in both core and user land. Would it be worth implementing this as an official API? It would be, I guess, Here is the illogical output for what I'd imagine are common paradigms: > assert.fail()
AssertionError: undefined undefined undefined
at repl:1:8
at ...
> assert.fail('uh oh!')
AssertionError: 'uh oh!' undefined undefined
at repl:1:8
at ...
> assert.fail(1e2, 1e3, 'not equal', '!==')
AssertionError: not equal
at repl:1:8
at ... Yes, I'm aware people want to lock this as a module but this I think is a good reason why it shouldn't be done. This is already expected for the most part. This shouldn't hold this up though, just tangential. |
@jasnell is this ready to land? |
@thealphanerd if you could amend the commit message so that the body wraps at 72 chars as specified in CONTRIBUTING.md, that will save James or whoever lands this that little step. Might as well rebase against current master while you're at it just to suss out any conflicts that may have arisen with commits from the last 2 days. |
Currently there are many instances where assert.fail is directly passed to a callback for error handling. Unfortunately this will swallow the error as it is the third argument of assert.fail that sets the message not the first. This commit adds a new function to test/common.js that simply wraps assert.fail and calls it with the provided message. Tip of the hat to @Trott for pointing me in the direction of this.
Landed in 28e9a02 |
Currently there are many instances where assert.fail is directly passed to a callback for error handling. Unfortunately this will swallow the error as it is the third argument of assert.fail that sets the message not the first. This commit adds a new function to test/common.js that simply wraps assert.fail and calls it with the provided message. Tip of the hat to @Trott for pointing me in the direction of this. PR-URL: #3453 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Currently there are many instances where assert.fail is directly passed to a callback for error handling. Unfortunately this will swallow the error as it is the third argument of assert.fail that sets the message not the first. This commit adds a new function to test/common.js that simply wraps assert.fail and calls it with the provided message. Tip of the hat to @Trott for pointing me in the direction of this. PR-URL: #3453 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Landed in v4.x-staging in 635f743 |
Currently there are many instances where assert.fail is directly passed to a callback for error handling. Unfortunately this will swallow the error as it is the third argument of assert.fail that sets the message not the first. This commit adds a new function to test/common.js that simply wraps assert.fail and calls it with the provided message. Tip of the hat to @Trott for pointing me in the direction of this. PR-URL: #3453 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Currently there are many instances where assert.fail is directly passed to a callback for error handling. Unfortunately this will swallow the error as it is the third argument of assert.fail that sets the message not the first. This commit adds a new function to test/common.js that simply wraps assert.fail and calls it with the provided message. Tip of the hat to @Trott for pointing me in the direction of this. PR-URL: #3453 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Rich Trott <[email protected]>
Currently there are many instances where assert.fail is directly passed
to a callback for error handling. Unfortunately this will swallow the error
as it is the third argument of assert.fail that sets the message not the first.
This commit adds a new function to test/common.js that simply wraps assert.fail
and calls it with the provided message.
Tip of the hat to @Trott for pointing me in the direction of this.