Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: Improve rejects/throws validation handling #1635
Assert: Improve rejects/throws validation handling #1635
Changes from 1 commit
68af124
ee3b1a3
df87aed
68aad74
939ab66
6344ba7
bbeb736
ebe0a53
d9f9a5f
a17ef1a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 haven't confirmed it, but it seems from reading the removed code, that previously a
null
expected value would reach theelse
branch that reports "invalid expected value provided". If so, did you mean to change that?I didn't actually realize that null (non-object and unboxable primitive) was valid in a throw statement, but it looks like it actually is possible to throw
null
(the same way strings and numbers can be thrown).I'm neutral on whether we need to support that, but I think the current state might be a bit strange, to have
null
behave the same as no argument, e.g. when would one useassert.throws(fn, null)
instead ofassert.throws(fn)
?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.
The old
throws
logic actually used a!expected
check(assert.js#L325), so undefined, null, false, 0, etc could all make it through here to be "valid" with no matching at all, just that it threw.
The old
rejects
logic used a more explicitexpected === undefined
check (assert.js#L435), so the null/false/0 sort of values would be considered invalid and produce failures. That made for some inconsistencies between the two.To target the "nullish" values, I went with
expected === undefined || expected === null
. So I've restricted the null/false/0 values for both (which now throw, not fail), but now anull
expected value forrejects
has changed from an invalid type to a valid/ignored one. I could go one further and restrict it to onlyundefined
, so that anull
value would error as well for both.What do you think?
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 think any value other than
undefined
should either be considered invalid, or be used as comparison target in some way. Usingnull
in this way would be unexpected, in my opinion. I did not realize thatassert.throws()
was implicitly allowing null and other falsely values as if they are undefined. We probably shouldn't change that in a minor release.Basically,
undefined
is here to represent the case of noexpected
parameter being passed and asserting only that something was thrown. A stricter version of this code would have usedarguments.length
to detect that, instead of comparing to undefined.Two ideas:
!expected
(assuming empty string remains invalid and handled earlier). That should not cause any previously passing code to start failing, and will temporarily laxrejects()
to start tolerating any other garbage passed to it. Assumign that people's existing tests are passing, this should not change any behaviour, but will add a temporary blind splot. Then in 3.0 we could change it to=== undefined
(orarguments.length
) and consider unhandled types as invalid.method
such that the behaviour remains the same for both. The throws branch accepts falsey as alias for undefined, the rejects branch considers non-undefined falsey values as invalid. The throws branch can then be deprecated in a follow-up commit.