assert: fix AssertException, assign error code #12651

jasnell · 2017-04-25T20:22:56Z

Using assert.AssertException() without the new keyword results in a non-intuitive error:

> assert.AssertionError({})
TypeError: Cannot assign to read only property 'name' of function 'function ok(value, message) {
  if (!value) fail(value, true, message, '==', assert.ok);
}'
    at Function.AssertionError (assert.js:45:13)
    at repl:1:8
    at realRunInThisContextScript (vm.js:22:35)
    at sigintHandlersWrap (vm.js:98:12)
    at ContextifyScript.Script.runInThisContext (vm.js:24:12)
    at REPLServer.defaultEval (repl.js:346:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:545:10)
    at emitOne (events.js:101:20)
>

The assert.AssertionError() can only be used correctly with new, so this converts it into a proper ES6 class that will give an appropriate error message.

This also associates the appropriate internal/errors code with all assert.AssertionError instances and updates the appropriate test cases.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

assert

Trott · 2017-04-25T22:28:19Z

~~If I'm understanding correctly, this makes new AssertionError() work if assert module has been required. Otherwise, one will get a ReferenceError when trying to create an AssertionError?~~

~~Are we OK with that sort of magic? (AssertionError exists if assert has been required but otherwise not.)~~

Trott · 2017-04-25T22:29:54Z

Ooops! No, I misread it entirely and I'm totally wrong, I think. Ignore my comment! :-D

jasnell · 2017-04-25T22:30:18Z

@Trott ... heh... AssertionError is already exported by assert... it's already a requirement to require('assert') to use it.

Trott · 2017-04-25T22:34:48Z

lib/assert.js

-
-function truncate(s, n) {
-  return s.slice(0, n);
+// TODO(jasnell): Consider moving AssertionError into internal/errors.js


Nit: I dislike TODO comments because they tend to confuse others rather than communicate clearly what's going on. See all the longstanding TODOs that we just can't seem to address and all the confusion it sows for people reading them in #4641 #4642 #4640

In this case, what are the considerations? I'd rather see this opened as a separate issue with full sentences and paragraphs explaining the issue.

On the other hand, bonus points for putting your name there so at least the reader knows who to ask.

You can totally ignore this nit, of course. But in the off-chance you agree, then please open an issue.

I expected at least one person to ask about this one :-) ... if we think it's a good idea, then I can just add a commit to this PR that moves it. It would be a minimally invasive change and would allow us to simplify some of the code. I just didn't do it yet because I want to know if there are any objections before doing so.

TODO comments like this are still better than not having them, IMO.

Trott · 2017-04-25T22:39:25Z

SGTM in principle. Since this involves significant changes to lib/assert.js and that happens to be one of the files we have complete test coverage for, it would be great if a coverage run could confirm that we still have 100% coverage across the board for it after these changes. I haven't tried to do a coverage run locally myself so I'm actually not sure how much work that is. If it's onerous, never mind. :-D

jasnell · 2017-04-25T22:46:12Z

I'll give the coverage run a go, but considering the fact that the tests had not previously caught that calling assert.AssertionError() without new was throwing a not-so-useful error, the 100% coverage is just a tad bit dubious ;-)

Trott · 2017-04-25T22:54:32Z

I'll give the coverage run a go, but considering the fact that the tests had not previously caught that calling assert.AssertionError() without new was throwing a not-so-useful error, the 100% coverage is just a tad bit dubious ;-)

I know you're being facetious (I hope), but that won't stop me from saying: 100% coverage just means that all the code gets exercised, not that there are no unhelpful error messages or (for that matter) bugs. 100% coverage isn't a guarantee that everything is tested. But 90% coverage is a guarantee that not everything is tested. So let's keep it at 100%. :-)

jasnell · 2017-04-25T23:05:18Z

Yes I am being facetious ;-) ... I'm running the coverage report now

jasnell · 2017-04-26T03:42:50Z

@Trott ... updated! This should have 100% coverage on the assert module now

jasnell · 2017-04-27T16:56:08Z

Ping @Trott (and other @nodejs/ctc)

jasnell · 2017-04-27T18:48:53Z

CI: https://ci.nodejs.org/job/node-test-pull-request/7708/

Fishrock123 · 2017-04-27T18:49:10Z

No comment on the code but +1 to the idea.

Trott · 2017-04-27T19:01:01Z

CI is failing. Something needs some adjusting....

jasnell · 2017-04-27T19:06:49Z

Ah... yeah, non-obvious rebase conflict. Rebasing and updating now.

jasnell · 2017-04-27T19:16:20Z

New CI: https://ci.nodejs.org/job/node-test-pull-request/7712/

jasnell · 2017-04-27T22:19:26Z

CI is green.

Using `assert.AssertException()` without the `new` keyword results in a non-intuitive error: ```js > assert.AssertionError({}) TypeError: Cannot assign to read only property 'name' of function 'function ok(value, message) { if (!value) fail(value, true, message, '==', assert.ok); }' at Function.AssertionError (assert.js:45:13) at repl:1:8 at realRunInThisContextScript (vm.js:22:35) at sigintHandlersWrap (vm.js:98:12) at ContextifyScript.Script.runInThisContext (vm.js:24:12) at REPLServer.defaultEval (repl.js:346:29) at bound (domain.js:280:14) at REPLServer.runBound [as eval] (domain.js:293:12) at REPLServer.onLine (repl.js:545:10) at emitOne (events.js:101:20) > ``` The `assert.AssertionError()` can only be used correctly with `new`, so this converts it into a proper ES6 class that will give an appropriate error message. This also associates the appropriate internal/errors code with all `assert.AssertionError` instances and updates the appropriate test cases.

jasnell · 2017-04-29T16:46:16Z

ping @nodejs/ctc ... I'd like to get this landed in time for 8.0.0 :-)

mhdawson

LGTM and nice to see ongoing progress on supporting error codes.

jasnell · 2017-05-04T14:11:56Z

Landed in 3f34ede

targos · 2017-05-04T14:14:24Z

Shouldn't it be "AssertionError" instead of "AssertException" in the commit message?

jasnell · 2017-05-04T14:18:09Z

doh! ok, we're still within the ten minutes so I'm going to push a fix

jasnell · 2017-05-04T14:19:22Z

fixed!

Using `assert.AssertionError()` without the `new` keyword results in a non-intuitive error: ```js > assert.AssertionError({}) TypeError: Cannot assign to read only property 'name' of function 'function ok(value, message) { if (!value) fail(value, true, message, '==', assert.ok); }' at Function.AssertionError (assert.js:45:13) at repl:1:8 at realRunInThisContextScript (vm.js:22:35) at sigintHandlersWrap (vm.js:98:12) at ContextifyScript.Script.runInThisContext (vm.js:24:12) at REPLServer.defaultEval (repl.js:346:29) at bound (domain.js:280:14) at REPLServer.runBound [as eval] (domain.js:293:12) at REPLServer.onLine (repl.js:545:10) at emitOne (events.js:101:20) > ``` The `assert.AssertionError()` can only be used correctly with `new`, so this converts it into a proper ES6 class that will give an appropriate error message. This also associates the appropriate internal/errors code with all `assert.AssertionError` instances and updates the appropriate test cases. PR-URL: #12651 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

Using `assert.AssertionError()` without the `new` keyword results in a non-intuitive error: ```js > assert.AssertionError({}) TypeError: Cannot assign to read only property 'name' of function 'function ok(value, message) { if (!value) fail(value, true, message, '==', assert.ok); }' at Function.AssertionError (assert.js:45:13) at repl:1:8 at realRunInThisContextScript (vm.js:22:35) at sigintHandlersWrap (vm.js:98:12) at ContextifyScript.Script.runInThisContext (vm.js:24:12) at REPLServer.defaultEval (repl.js:346:29) at bound (domain.js:280:14) at REPLServer.runBound [as eval] (domain.js:293:12) at REPLServer.onLine (repl.js:545:10) at emitOne (events.js:101:20) > ``` The `assert.AssertionError()` can only be used correctly with `new`, so this converts it into a proper ES6 class that will give an appropriate error message. This also associates the appropriate internal/errors code with all `assert.AssertionError` instances and updates the appropriate test cases. PR-URL: nodejs#12651 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>

jasnell added assert Issues and PRs related to the assert subsystem. errors Issues and PRs related to JavaScript errors originated in Node.js core. semver-major PRs that contain breaking changes and should be released in the next major version. labels Apr 25, 2017

nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Apr 25, 2017

addaleax approved these changes Apr 25, 2017

View reviewed changes

Trott reviewed Apr 25, 2017

View reviewed changes

jasnell force-pushed the fix-assert-assertionerror branch from cc5a090 to 5648ed5 Compare April 27, 2017 19:15

jasnell force-pushed the fix-assert-assertionerror branch from 5648ed5 to 8a70aa9 Compare April 28, 2017 00:01

jasnell added this to the 8.0.0 milestone Apr 28, 2017

mhdawson approved these changes May 3, 2017

View reviewed changes

jasnell closed this May 4, 2017

jasnell mentioned this pull request May 11, 2017

8.0.0 Release Proposal #12220

Closed

azu mentioned this pull request Jun 1, 2017

Unable to compose power-assert + espower in vanilla node 7 or 8 power-assert-js/power-assert#85

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

assert: fix AssertException, assign error code #12651

assert: fix AssertException, assign error code #12651

jasnell commented Apr 25, 2017 •

edited

Loading

Trott commented Apr 25, 2017 •

edited

Loading

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

Trott Apr 25, 2017

jasnell Apr 25, 2017

Fishrock123 Apr 27, 2017

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

jasnell commented Apr 26, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

Fishrock123 commented Apr 27, 2017

Trott commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 29, 2017

mhdawson left a comment

jasnell commented May 4, 2017

targos commented May 4, 2017

jasnell commented May 4, 2017

jasnell commented May 4, 2017

assert: fix AssertException, assign error code #12651

assert: fix AssertException, assign error code #12651

Conversation

jasnell commented Apr 25, 2017 • edited Loading

Checklist

Affected core subsystem(s)

Trott commented Apr 25, 2017 • edited Loading

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

Trott Apr 25, 2017

Choose a reason for hiding this comment

jasnell Apr 25, 2017

Choose a reason for hiding this comment

Fishrock123 Apr 27, 2017

Choose a reason for hiding this comment

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

Trott commented Apr 25, 2017

jasnell commented Apr 25, 2017

jasnell commented Apr 26, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

Fishrock123 commented Apr 27, 2017

Trott commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 27, 2017

jasnell commented Apr 29, 2017

mhdawson left a comment

Choose a reason for hiding this comment

jasnell commented May 4, 2017

targos commented May 4, 2017

jasnell commented May 4, 2017

jasnell commented May 4, 2017

jasnell commented Apr 25, 2017 •

edited

Loading

Trott commented Apr 25, 2017 •

edited

Loading