|
|
|
|
// Flags: --expose-internals
|
|
|
|
|
'use strict';
|
|
|
|
|
|
|
|
|
|
const common = require('../common');
|
|
|
|
|
const errors = require('internal/errors');
|
|
|
|
|
const assert = require('assert');
|
|
|
|
|
|
|
|
|
|
errors.E('TEST_ERROR_1', 'Error for testing purposes: %s');
|
|
|
|
|
errors.E('TEST_ERROR_2', (a, b) => `${a} ${b}`);
|
|
|
|
|
|
|
|
|
|
const err1 = new errors.Error('TEST_ERROR_1', 'test');
|
|
|
|
|
const err2 = new errors.TypeError('TEST_ERROR_1', 'test');
|
|
|
|
|
const err3 = new errors.RangeError('TEST_ERROR_1', 'test');
|
|
|
|
|
const err4 = new errors.Error('TEST_ERROR_2', 'abc', 'xyz');
|
|
|
|
|
const err5 = new errors.Error('TEST_ERROR_1');
|
|
|
|
|
|
|
|
|
|
assert(err1 instanceof Error);
|
|
|
|
|
assert.strictEqual(err1.name, 'Error [TEST_ERROR_1]');
|
|
|
|
|
assert.strictEqual(err1.message, 'Error for testing purposes: test');
|
|
|
|
|
assert.strictEqual(err1.code, 'TEST_ERROR_1');
|
|
|
|
|
|
|
|
|
|
assert(err2 instanceof TypeError);
|
|
|
|
|
assert.strictEqual(err2.name, 'TypeError [TEST_ERROR_1]');
|
|
|
|
|
assert.strictEqual(err2.message, 'Error for testing purposes: test');
|
|
|
|
|
assert.strictEqual(err2.code, 'TEST_ERROR_1');
|
|
|
|
|
|
|
|
|
|
assert(err3 instanceof RangeError);
|
|
|
|
|
assert.strictEqual(err3.name, 'RangeError [TEST_ERROR_1]');
|
|
|
|
|
assert.strictEqual(err3.message, 'Error for testing purposes: test');
|
|
|
|
|
assert.strictEqual(err3.code, 'TEST_ERROR_1');
|
|
|
|
|
|
|
|
|
|
assert(err4 instanceof Error);
|
|
|
|
|
assert.strictEqual(err4.name, 'Error [TEST_ERROR_2]');
|
|
|
|
|
assert.strictEqual(err4.message, 'abc xyz');
|
|
|
|
|
assert.strictEqual(err4.code, 'TEST_ERROR_2');
|
|
|
|
|
|
|
|
|
|
assert(err5 instanceof Error);
|
|
|
|
|
assert.strictEqual(err5.name, 'Error [TEST_ERROR_1]');
|
|
|
|
|
assert.strictEqual(err5.message, 'Error for testing purposes: %s');
|
|
|
|
|
assert.strictEqual(err5.code, 'TEST_ERROR_1');
|
|
|
|
|
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error('TEST_FOO_KEY'),
|
|
|
|
|
/^AssertionError: An invalid error message key was used: TEST_FOO_KEY\.$/);
|
|
|
|
|
// Calling it twice yields same result (using the key does not create it)
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error('TEST_FOO_KEY'),
|
|
|
|
|
/^AssertionError: An invalid error message key was used: TEST_FOO_KEY\.$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error(1),
|
|
|
|
|
/^AssertionError: 'number' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error({}),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error([]),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.Error(true),
|
|
|
|
|
/^AssertionError: 'boolean' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.TypeError(1),
|
|
|
|
|
/^AssertionError: 'number' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.TypeError({}),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.TypeError([]),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.TypeError(true),
|
|
|
|
|
/^AssertionError: 'boolean' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.RangeError(1),
|
|
|
|
|
/^AssertionError: 'number' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.RangeError({}),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.RangeError([]),
|
|
|
|
|
/^AssertionError: 'object' === 'string'$/);
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => new errors.RangeError(true),
|
|
|
|
|
/^AssertionError: 'boolean' === 'string'$/);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// Tests for common.expectsError
|
|
|
|
|
assert.doesNotThrow(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1' }));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert.doesNotThrow(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1',
|
|
|
|
|
type: TypeError,
|
|
|
|
|
message: /^Error for testing/ }));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert.doesNotThrow(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1', type: TypeError }));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert.doesNotThrow(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1', type: Error }));
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1', type: RangeError }));
|
|
|
|
|
}, /^AssertionError: .+ is not the expected type \S/);
|
|
|
|
|
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
assert.throws(() => {
|
|
|
|
|
throw new errors.TypeError('TEST_ERROR_1', 'a');
|
test: change common.expectsError() signature
One downside to `common.expectsError()` is that it increases the
abstractions people have to learn about in order to work with even
simple tests. Whereas before, all they had to know about is
`assert.throws()`, now they have to *also* know about
`common.expectsError()`. This is very different (IMO) from
`common.mustCall()` in that the latter has an intuitively understandable
name, accepts arguments as one would expect, and (in most cases) doesn't
actually require reading documentation or code to figure out what it's
doing. With `common.expectsError()`, there's a fair bit of magic. Like,
it's not obvious what the first argument would be. Or the second. Or the
third. You just have to know.
This PR changes the arguments accepted by `common.expectsError()` to a
single settings object. Someone coming across this has a hope of
understanding what's going on without reading source or docs:
```js
const validatorFunction = common.expectsError({code: 'ELOOP',
type: Error,
message: 'foo'});
```
This, by comparison, is harder to grok:
```js
const validatorFunction = common.expectsError('ELOOP',
Error,
'foo');
```
And this is especially wat-inducing:
```js
common.expectsError(undefined, undefined, 'looped doodad found');
```
It's likely that only people who work with tests frequently can be
expected to remember the three arguments and their order. By comparison,
remembering that the error code is `code` and the message is `message`
might be manageable.
PR-URL: https://github.com/nodejs/node/pull/11512
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
8 years ago
|
|
|
}, common.expectsError({ code: 'TEST_ERROR_1',
|
|
|
|
|
type: TypeError,
|
|
|
|
|
message: /^Error for testing 2/ }));
|
|
|
|
|
}, /AssertionError: .+ does not match \S/);
|
|
|
|
|
|
|
|
|
|
assert.doesNotThrow(() => errors.E('TEST_ERROR_USED_SYMBOL'));
|
|
|
|
|
assert.throws(
|
|
|
|
|
() => errors.E('TEST_ERROR_USED_SYMBOL'),
|
|
|
|
|
/^AssertionError: Error symbol: TEST_ERROR_USED_SYMBOL was already used\.$/
|
|
|
|
|
);
|
