You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

75 lines
2.6 KiB

process: add 'warning' event and process.emitWarning() In several places throughout the code we write directly to stderr to report warnings (deprecation, possible eventemitter memory leak). The current design of simply dumping the text to stderr is less than ideal. This PR introduces a new "process warnings" mechanism that emits 'warning' events on the global process object. These are invoked with a `warning` argument whose value is an Error object. By default, these warnings will be printed to stderr. This can be suppressed using the `--no-warnings` and `--no-deprecation` command line flags. For warnings, the 'warning' event will still be emitted by the process, allowing applications to handle the warnings in custom ways. The existing `--no-deprecation` flag will continue to supress all deprecation output generated by the core lib. The `--trace-warnings` command line flag will tell Node.js to print the full stack trace of warnings as part of the default handling. The existing `--no-deprecation`, `--throw-deprecation` and `--trace-deprecation` flags continue to work as they currently do, but the exact output of the warning message is modified to occur on process.nextTick(). The stack trace for the warnings and deprecations preserve and point to the correct call site. A new `process.emitWarning()` API is provided to permit userland to emit warnings and deprecations using the same consistent mechanism. Test cases and documentation are included. PR-URL: https://github.com/nodejs/node/pull/4782 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
9 years ago
// Flags: --no-warnings
// The flag suppresses stderr output but the warning event will still emit
'use strict';
const common = require('../common');
const assert = require('assert');
const testMsg = 'A Warning';
const testCode = 'CODE001';
const testDetail = 'Some detail';
const testType = 'CustomWarning';
process: add 'warning' event and process.emitWarning() In several places throughout the code we write directly to stderr to report warnings (deprecation, possible eventemitter memory leak). The current design of simply dumping the text to stderr is less than ideal. This PR introduces a new "process warnings" mechanism that emits 'warning' events on the global process object. These are invoked with a `warning` argument whose value is an Error object. By default, these warnings will be printed to stderr. This can be suppressed using the `--no-warnings` and `--no-deprecation` command line flags. For warnings, the 'warning' event will still be emitted by the process, allowing applications to handle the warnings in custom ways. The existing `--no-deprecation` flag will continue to supress all deprecation output generated by the core lib. The `--trace-warnings` command line flag will tell Node.js to print the full stack trace of warnings as part of the default handling. The existing `--no-deprecation`, `--throw-deprecation` and `--trace-deprecation` flags continue to work as they currently do, but the exact output of the warning message is modified to occur on process.nextTick(). The stack trace for the warnings and deprecations preserve and point to the correct call site. A new `process.emitWarning()` API is provided to permit userland to emit warnings and deprecations using the same consistent mechanism. Test cases and documentation are included. PR-URL: https://github.com/nodejs/node/pull/4782 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
9 years ago
process.on('warning', common.mustCall((warning) => {
assert(warning);
assert(/^(Warning|CustomWarning)/.test(warning.name));
assert.strictEqual(warning.message, testMsg);
if (warning.code) assert.strictEqual(warning.code, testCode);
if (warning.detail) assert.strictEqual(warning.detail, testDetail);
}, 15));
class CustomWarning extends Error {
constructor() {
super();
this.name = testType;
this.message = testMsg;
this.code = testCode;
Error.captureStackTrace(this, CustomWarning);
}
process: add 'warning' event and process.emitWarning() In several places throughout the code we write directly to stderr to report warnings (deprecation, possible eventemitter memory leak). The current design of simply dumping the text to stderr is less than ideal. This PR introduces a new "process warnings" mechanism that emits 'warning' events on the global process object. These are invoked with a `warning` argument whose value is an Error object. By default, these warnings will be printed to stderr. This can be suppressed using the `--no-warnings` and `--no-deprecation` command line flags. For warnings, the 'warning' event will still be emitted by the process, allowing applications to handle the warnings in custom ways. The existing `--no-deprecation` flag will continue to supress all deprecation output generated by the core lib. The `--trace-warnings` command line flag will tell Node.js to print the full stack trace of warnings as part of the default handling. The existing `--no-deprecation`, `--throw-deprecation` and `--trace-deprecation` flags continue to work as they currently do, but the exact output of the warning message is modified to occur on process.nextTick(). The stack trace for the warnings and deprecations preserve and point to the correct call site. A new `process.emitWarning()` API is provided to permit userland to emit warnings and deprecations using the same consistent mechanism. Test cases and documentation are included. PR-URL: https://github.com/nodejs/node/pull/4782 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
9 years ago
}
[
[testMsg],
[testMsg, testType],
[testMsg, CustomWarning],
[testMsg, testType, CustomWarning],
[testMsg, testType, testCode],
[testMsg, { type: testType }],
[testMsg, { type: testType, code: testCode }],
[testMsg, { type: testType, code: testCode, detail: testDetail }],
[new CustomWarning()],
// detail will be ignored for the following. No errors thrown
[testMsg, { type: testType, code: testCode, detail: true }],
[testMsg, { type: testType, code: testCode, detail: [] }],
[testMsg, { type: testType, code: testCode, detail: null }],
[testMsg, { type: testType, code: testCode, detail: 1 }]
].forEach((i) => {
assert.doesNotThrow(() => process.emitWarning.apply(null, i));
});
process: add 'warning' event and process.emitWarning() In several places throughout the code we write directly to stderr to report warnings (deprecation, possible eventemitter memory leak). The current design of simply dumping the text to stderr is less than ideal. This PR introduces a new "process warnings" mechanism that emits 'warning' events on the global process object. These are invoked with a `warning` argument whose value is an Error object. By default, these warnings will be printed to stderr. This can be suppressed using the `--no-warnings` and `--no-deprecation` command line flags. For warnings, the 'warning' event will still be emitted by the process, allowing applications to handle the warnings in custom ways. The existing `--no-deprecation` flag will continue to supress all deprecation output generated by the core lib. The `--trace-warnings` command line flag will tell Node.js to print the full stack trace of warnings as part of the default handling. The existing `--no-deprecation`, `--throw-deprecation` and `--trace-deprecation` flags continue to work as they currently do, but the exact output of the warning message is modified to occur on process.nextTick(). The stack trace for the warnings and deprecations preserve and point to the correct call site. A new `process.emitWarning()` API is provided to permit userland to emit warnings and deprecations using the same consistent mechanism. Test cases and documentation are included. PR-URL: https://github.com/nodejs/node/pull/4782 Reviewed-By: Rod Vagg <rod@vagg.org> Reviewed-By: Wyatt Preul <wpreul@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
9 years ago
const warningNoToString = new CustomWarning();
warningNoToString.toString = null;
process.emitWarning(warningNoToString);
const warningThrowToString = new CustomWarning();
warningThrowToString.toString = function() {
throw new Error('invalid toString');
};
process.emitWarning(warningThrowToString);
const expectedError =
common.expectsError({code: 'ERR_INVALID_ARG_TYPE', type: TypeError});
// TypeError is thrown on invalid input
assert.throws(() => process.emitWarning(1), expectedError);
assert.throws(() => process.emitWarning({}), expectedError);
assert.throws(() => process.emitWarning(true), expectedError);
assert.throws(() => process.emitWarning([]), expectedError);
assert.throws(() => process.emitWarning('', '', {}), expectedError);
assert.throws(() => process.emitWarning('', 1), expectedError);
assert.throws(() => process.emitWarning('', '', 1), expectedError);
assert.throws(() => process.emitWarning('', true), expectedError);
assert.throws(() => process.emitWarning('', '', true), expectedError);
assert.throws(() => process.emitWarning('', []), expectedError);
assert.throws(() => process.emitWarning('', '', []), expectedError);