-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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: inconsistency in assert.doesNotThrow #2385
Comments
Related: nodejs/node-v0.x-archive#6580 The docs show different signatures for |
Terribly sorry for the mess above! |
@jasnell |
I'm working on updating the documentation but first I want clarify the behavior of // if not the right exception or if did not expect an exception
// then rethrow
if ((shouldThrow && actual && expected &&
!expectedException(actual, expected)) || (!shouldThrow && actual)) {
throw actual;
} and this simply rethrows the error from the block. That seems inconsistent and counter-intuitive as I, at least, would've expected |
The Assert API is now Locked. Should this be closed? Or is this a bug fix? Does it matter that it's a bug that does not seem to adversely affect Node.js project tests? |
Addresses nodejs#2385. Special handling to detect when user has supplied a custom message. Added a test for user message. When testing if `actual` value is an error use `util.isError` instead of `instanceof`.
Special handling to detect when user has supplied a custom message. Added a test for user message. When testing if `actual` value is an error use `util.isError` instead of `instanceof`. Fixes: nodejs#2385 PR-URL: nodejs#2407 Reviewed-By: James M Snell <jasnell@gmail.com>
There's still a problem with it, if the second argument is not callable then it will always throw "Got unwanted exception.." instead of the actual exception, which contradicts the documentation which clearly states if the second argument is falsy it will throw the original exception. I currently resolve the bug with;
Documentation: If an error is thrown and it is the same type as that specified by the error parameter, then an AssertionError is thrown. If the error is of a different type, or if the error parameter is undefined, the error is propagated back to the caller. // tested with 7.10.0 |
This is fixed in current master. Closing. (Comment or re-open or open a new issue if I'm wrong.) |
nodejs/node-v0.x-archive#6470 is an old PR that never landed but points to a valid issue.
The test case:
Prints the error stack but does not output an AssertionError.
However,
Raises an Assertion Error (
AssertionError: Got unwanted exception (Error)..
And
Both just output
custom message
without raising the Assertion Error.The solution submitted in nodejs/node-v0.x-archive#6470 should be investigated as a possible fix but possibly needs to be revisited.
The text was updated successfully, but these errors were encountered: