assert: use a default message in assert

[BridgeAR]

In case no arguments are passed to assert.ok it should just
use a default message. Otherwise assert.ok can not be used as
a callback.

The PR that changed the behavior before is semver-major and has not yet been released.
So I just changed the original changed entry.

The reason for the change is something like this:

const assert = require('assert');
const EventEmitter = require('events');

const e = new EventEmitter();
e.once('hello', assert);
e.emit('hello');

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

[apapirovski]

I really can't decide how I feel about this... I can't even decide how I feel about the original change. I mean, assert.strictEqual() doesn't throw an assertion right now, right? Seems strange that assert.ok() is the one exception...

[BridgeAR]

@apapirovski yes, assert.strictEqual() returns true. That is the case because "both" values are undefined. assert.notStrictEqual() throws. Enforcing the value was originally meant to get people to use assert.fail() in such a case. But as there are actually more use cases, a default message is probably better than undefined == true, don't you agree? (because the latter is actually what this PR is about to do)

[vsemozhetbyt]

Incomplete sentence?

[BridgeAR]

Uh, somehow I did not finish it... solved.

[BridgeAR]

Rebased due to conflicts.

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

[joyeecheung]

Umm, press the button too soon...how does changing this to ERR_ASSERTION makes it possible to be used in callbacks?

[BridgeAR]

@joyeecheung i tried to highlight that in the descriptionof the PR. It it all about not providing a value. An error will be thrown one way or the other, the question is what error. I personally reconsidered and think a default is best in such a case.

[joyeecheung]

@BridgeAR By default do you mean "AssertionError: No value argument passed to assert.ok? Why is it better than ERR_MISSING_ARGS though?

[BridgeAR]

@joyeecheung yes, that is what I mean. It might be "expected" behavior to not pass in a value in that case. That would probably mainly be the case by using e.g. spread (assert.ok(...input)) or by something like Reflect.apply.

In both cases we notify the user that no arguments were passed to the function but with this PR it is "acceptable" to do so. With the current implementation it is considered a faulty behavior.

[joyeecheung]

@BridgeAR I think I understand now, thanks. With the example in OP:

assert.js:72
  throw new AssertionError(obj);
  ^

AssertionError [ERR_ASSERTION]: No value argument passed to `assert.ok()`
    at Object.onceWrapper (events.js:223:13)
    at EventEmitter.emit (events.js:131:13)
    at Object.<anonymous> (/Users/joyee/projects/node/assert-test.js:7:3)
    at Module._compile (module.js:661:30)
    at Object.Module._extensions..js (module.js:672:10)
    at Module.load (module.js:578:32)
    at tryModuleLoad (module.js:518:12)
    at Function.Module._load (module.js:510:3)
    at Function.Module.runMain (module.js:702:10)
    at startup (bootstrap_node.js:194:16)

assert.js:141
    throw new TypeError('ERR_MISSING_ARGS', 'value');
    ^

TypeError [ERR_MISSING_ARGS]: The "value" argument must be specified
    at innerOk (assert.js:141:11)
    at EventEmitter.ok (assert.js:222:3)
    at Object.onceWrapper (events.js:223:13)
    at EventEmitter.emit (events.js:131:13)
    at Object.<anonymous> (/Users/joyee/projects/node/assert-test.js:7:3)
    at Module._compile (module.js:661:30)
    at Object.Module._extensions..js (module.js:672:10)
    at Module.load (module.js:578:32)
    at tryModuleLoad (module.js:518:12)
    at Function.Module._load (module.js:510:3)

The first one does seem to be less confusing, although I am not sure if ERR_ASSERTION is better than ERR_MISSING_ARGS in this case, but I would not block it. Can you add a test to demonstrate how it would be useful? Something like in the OP or with assert(...[]) would be fine.

answered

[mcollina]

LGTM

[BridgeAR]

@joyeecheung I changed a testcase to outline the use case further.

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

[BridgeAR]

Landed in 3cd7977