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: support custom errors #15304

Closed
wants to merge 1 commit into from
Closed

assert: support custom errors #15304

wants to merge 1 commit into from

Conversation

geek
Copy link
Member

@geek geek commented Sep 10, 2017

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
Affected core subsystem(s)

assert - support a way to provide a custom Error type for assertions. This will help make assert more useful for validating types and ranges.

@geek geek requested a review from cjihrig September 10, 2017 01:47
@nodejs-github-bot nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Sep 10, 2017
Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

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

LGTM with a few suggestions. I think this is a useful change (helping with code coverage in modules using assert, and improving error types).

property set equal to the value of the `message` parameter. If the `message`
parameter is undefined, a default error message is assigned.
property set eq ual to the value of the `message` parameter. If the `message`
parameter is undefined, a default error message is assigned. f the `message`
Copy link
Contributor

Choose a reason for hiding this comment

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

f -> If

try {
assert.strictEqual(1, 2, new RangeError('my range'));
} catch (e) {
assert.strictEqual(e.message, 'my range');
Copy link
Contributor

Choose a reason for hiding this comment

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

If you store the RangeError in a variable, you can just assert that e equals it.

}, TypeError, new RangeError('my range'));
} catch (e) {
assert.ok(e.message.includes('my range'));
assert.ok(e instanceof assert.AssertionError);
Copy link
Contributor

Choose a reason for hiding this comment

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

For these tests involving try...catch, we don't know if the assertions were actually run. Can you add checks like these

@@ -411,8 +422,10 @@ assert.notDeepEqual(obj1, obj4);
```

If the values are deeply equal, an `AssertionError` is thrown with a `message`
property set equal to the value of the `message` parameter. If the `message`
parameter is undefined, a default error message is assigned.
property set eq ual to the value of the `message` parameter. If the `message`
Copy link
Contributor

Choose a reason for hiding this comment

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

eq ual -> equal

@cjihrig cjihrig added the semver-major PRs that contain breaking changes and should be released in the next major version. label Sep 10, 2017
@geek
Copy link
Member Author

geek commented Sep 11, 2017

@cjihrig @vsemozhetbyt thanks for the feedback... updated!

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.

In general I like the idea a lot!
LGTM but I think it would be nice to use common.expectsError

assert.ok(e instanceof RangeError, 'Incorrect error type thrown');
}
assert.ok(threw);
threw = false;
Copy link
Member

Choose a reason for hiding this comment

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

It would actually be nice to use common.expectsError here. The test would be smaller in that case. You can check some other use cases as a reference.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for the suggestion. I tried expectsError, but for this simple case it didn't make the code any cleaner/shorter/simpler. I'm keeping it as is for now.

@cjihrig
Copy link
Contributor

cjihrig commented Sep 12, 2017

@cjihrig
Copy link
Contributor

cjihrig commented Sep 12, 2017

Landed in e13d1df. Thanks!

@cjihrig cjihrig closed this Sep 12, 2017
cjihrig pushed a commit that referenced this pull request Sep 12, 2017
This commit adds special handling of Error instances when passed
as the message argument to assert functions. With this commit,
if an Error is passed as the message, then that Error is thrown
instead of an AssertionError.

PR-URL: #15304
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
@geek geek deleted the assert branch September 12, 2017 19:06
@refack
Copy link
Contributor

refack commented Sep 12, 2017

I like the concept of this PR, but I think it was rushed.

  1. semver-majors need two TSC approvals (this one has only @cjihrig's)
  2. expectsError conceptualy should be used to validate internal/errors since theoretically it should assert that an err.code exists.
  3. The assert module, although it has been unfrozen, should get some extra attention, since it's a fundamental language construct (and we might want to hoist it into spec).

(I'm not saying it should be reverted, but I do suggest we tweak it a bit before 9.0.0)

@cjihrig
Copy link
Contributor

cjihrig commented Sep 12, 2017

@refack, definitely my bad on item 1. I apologize for that.

Regarding item 2, that is how the surrounding tests in that file are written, so I don't necessarily think that is wrong. Maybe that could be a good first contribution.

I don't really have any comment on item 3 other than the PR being open sufficiently long enough.

I do suggest we tweak it a bit before 9.0.0

Do you want to submit a follow up PR?

Again, my apologies for item 1.

@refack
Copy link
Contributor

refack commented Sep 12, 2017

I do suggest we tweak it a bit before 9.0.0
Do you want to submit a follow up PR?

I totally agree there's nothing bad in this PR (on the contrary, I see it's usufulness).
I'll try to either open a PR or a first-contribution issue.

addaleax pushed a commit to addaleax/node that referenced this pull request Sep 13, 2017
This commit adds special handling of Error instances when passed
as the message argument to assert functions. With this commit,
if an Error is passed as the message, then that Error is thrown
instead of an AssertionError.

PR-URL: nodejs#15304
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
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. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants