Skip to content
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

assert: fix internal logic judgment #27743

Closed
wants to merge 6 commits into from

Conversation

zero1five
Copy link
Contributor

Fix the logic judgment of assert.fail and add doc
and the test cases for the performance of assert.fail
on multiple parameter.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label May 16, 2019
@Trott Trott requested a review from BridgeAR May 17, 2019 21:03
@zero1five
Copy link
Contributor Author

review wanted.
If I miss something, please point. thank you very much!

doc/api/assert.md Outdated Show resolved Hide resolved
@Trott
Copy link
Member

Trott commented May 19, 2019

I'm honestly not sure this isn't a bug and the behavior should be as described in the docs currently. But I'm also not sure it's worth changing/"fixing" even if that's the case. This looks good to me, but maybe @BridgeAR or @refack would want to take a look?

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change does not seem right to me. All added test cases work identical as before with this patch besides the last one which should ideally print 'Failed' which it currently does.

The documentation could use an update though. My plane is about to take off so I'll review that later.

@zero1five zero1five force-pushed the fix/assert-fail-api branch 2 times, most recently from cde5202 to dfe1904 Compare May 19, 2019 08:17
@refack
Copy link
Contributor

refack commented May 19, 2019

Hello @zero1five, and thank you for the contribution!
I'm not sure I have anything of significance to contribute, except that since this makes changes around a deprecated signature, I'd like the distinction between the supported and deprecated signatures be as explicit as possible.

@BridgeAR
Copy link
Member

BridgeAR commented May 19, 2019

@zero1five assert.fail(undefined) should result in 'Failed' as outlined above. Resulting in 'undefined fail undefined' is not ideal at all. The default operator should also be != and not 'fail' in case the operator is undefined but more than a single argument is passed through.

@zero1five zero1five force-pushed the fix/assert-fail-api branch from dfe1904 to 9553caf Compare May 20, 2019 00:55
@zero1five
Copy link
Contributor Author

@BridgeAR Thank you very much for your review! I made some changes, can you please review it?

@zero1five zero1five force-pushed the fix/assert-fail-api branch from 7cb6eb0 to f8314d6 Compare May 21, 2019 12:08
Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sticking to it! I left a few more comments.

lib/assert.js Outdated Show resolved Hide resolved
lib/assert.js Show resolved Hide resolved
doc/api/assert.md Outdated Show resolved Hide resolved
@zero1five zero1five force-pushed the fix/assert-fail-api branch from f8314d6 to 7994c95 Compare May 22, 2019 16:45
Fix the logic judgment of assert.fail and add doc
and the test cases for the performance of assert.fail
on multiple parameter.
@zero1five zero1five force-pushed the fix/assert-fail-api branch from 5534055 to b87a772 Compare May 22, 2019 17:03
BridgeAR
BridgeAR previously approved these changes Jan 12, 2020
@BridgeAR
Copy link
Member

@zero1five sorry that it took a while to look at this again. Some times it's difficult to keep an overview over all the PRs.

This needs a rebase but I think this should otherwise be good to go.

@Trott would you please take another look at the docs?

doc/api/assert.md Outdated Show resolved Hide resolved
doc/api/assert.md Outdated Show resolved Hide resolved
given, the default message `Failed` will be used.
`expected` separated by the provided `operator`. If `operator` is falsy and no
message is set, it'll default to `'!='`. If `message` is truthy the `operator`
will default to `'fail'` and `message` will be used as error message. Other
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
will default to `'fail'` and `message` will be used as error message. Other
will default to `'fail'` and `message` will be used for the error message. Other

doc/api/assert.md Outdated Show resolved Hide resolved
@Trott
Copy link
Member

Trott commented Jan 26, 2020

@Trott would you please take another look at the docs?

I left some suggestions but they're all nits, This can land without them,.

actual: undefined,
expected: undefined,
generatedMessage: true
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test currently passes without the other changes in this PR. Can we please add a test case that currently fails?

Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a test case that fails on current master branch.

We should probably come up with a more detailed commit message to use while landing. (@BridgeAR: Any thoughts on that?)

@HarshithaKP
Copy link
Member

@zero1five, there are few review comments and this needs a rebase.

}

if (message instanceof Error) throw message;

if (operator === undefined) {
if (message) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (message) {
if (message != null) {

Comment on lines +67 to +74
assert.fail(undefined);
}, {
code: 'ERR_ASSERTION',
name: 'AssertionError',
message: 'Failed',
operator: 'fail',
actual: undefined,
expected: undefined,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
assert.fail(undefined);
}, {
code: 'ERR_ASSERTION',
name: 'AssertionError',
message: 'Failed',
operator: 'fail',
actual: undefined,
expected: undefined,
assert.fail(1, 2, undefined, undefined);
}, {
code: 'ERR_ASSERTION',
name: 'AssertionError',
message: '1 != 2',
operator: '!=',
actual: 1,
expected: 2,

Ideally, another identical test could be added that sets message to null.

Comment on lines +636 to +641
`expected` separated by the provided `operator`. If `operator` is falsy and no
message is set, it will default to `'!='`. If `message` is truthy, the `operator`
will default to `'fail'` and `message` will be used for the error message. Other
arguments will be stored as properties on the thrown object. If `stackStartFn`
is provided, all stack frames above that function will be removed from
stacktrace (see [`Error.captureStackTrace`][]).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to change the operator description above to explain when it's set to 'fail' and when to '!='.

I would also move the stackStartFn description to the part above. That way the total description below concentrates on the general behavior instead of describing each individual option setting.

Right now we also miss to document that assert.fail(1, 2, new Error() throws the passed through error. That could be described in the message property above.

@BridgeAR BridgeAR dismissed their stale review April 26, 2020 23:05

The comments should be addressed before this lands.

@BridgeAR BridgeAR force-pushed the master branch 2 times, most recently from 8ae28ff to 2935f72 Compare May 31, 2020 12:19
@jasnell jasnell added the stalled Issues and PRs that are stalled. label Jul 7, 2020
@jasnell
Copy link
Member

jasnell commented Jul 7, 2020

This would need a rebase in order to move forward

@jasnell jasnell closed this Jul 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. stalled Issues and PRs that are stalled.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants