Change error types emitted from request and validatePriorityOptions
to be TypeError rather than the incorrect RangeError. Add tests
to confirm that all errors are thrown as expected (weight, parent,
exclusive, silent, endStream and getTrailers). Add test for method
CONNECT throwing error on missing :authority or superfluous :scheme
and :path.
PR-URL: https://github.com/nodejs/node/pull/15109
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.
This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.
Fixes: https://github.com/nodejs/node/issues/14022
PR-URL: https://github.com/nodejs/node/pull/14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
covert lib/fs.js over to using lib/internal/errors.js
i have not addressed the cases that use errnoException(),
for reasons described in GH-12926
- throw the ERR_INVALID_CALLBACK error
when the the callback is invalid
- replace the ['object', 'string'] with
['string', 'object'] in the error constructor call,
to better match the previous err msg
in the getOptions() function
- add error ERR_VALUE_OUT_OF_RANGE in lib/internal/errors.js,
this error is thrown when a numeric value is out of range
- document the ERR_VALUE_OUT_OF_RANGE err in errors.md
- correct the expected args, in the error thrown in the function
fs._toUnixTimestamp() to ['Date', 'time in seconds'] (lib/fs.js)
- update the listener error type in the fs.watchFile() function,
from Error to TypeError (lib/fs.js)
- update errors from ERR_INVALID_OPT_VALUE to ERR_INVALID_ARG_TYPE
in the functions fs.ReadStream() and fs.WriteStream(),
for the cases of range errors use the new error:
ERR_VALUE_OUT_OF_RANGE (lib/fs.js)
PR-URL: https://github.com/nodejs/node/pull/15043
Refs: https://github.com/nodejs/node/issues/11273
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Adds an implementation for writeContinue based on the h2 spec & the
existing http implementation. ClientHttp2Stream now also emits
a continue event when it receives headers with :status 100.
Includes two test cases for default server continue behaviour and
for the exposed checkContinue listener.
PR-URL: https://github.com/nodejs/node/pull/15039
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Previously calling emitAfter() from _fatalException would skipt the
first asyncId. Instead use the size() of the std::stack to determine how
many times to loop and call emitAfter().
PR-URL: https://github.com/nodejs/node/pull/14914
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
This changes the error handling model of ServerHttp2Stream,
ServerHttp2Request and ServerHttp2Response.
An 'error' emitted on ServerHttp2Stream will not go to
'uncaughtException' anymore, but to the server 'streamError'.
On the stream 'error', ServerHttp2Request will emit 'abort', while
ServerHttp2Response would do nothing.
It also updates respondWith* to the new error handling.
Fixes: https://github.com/nodejs/node/issues/14963
PR-URL: https://github.com/nodejs/node/pull/14991
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This changes the error handling model of ServerHttp2Stream,
ServerHttp2Request and ServerHttp2Response.
An 'error' emitted on ServerHttp2Stream will not go to
'uncaughtException' anymore, but to the server 'streamError'.
On the stream 'error', ServerHttp2Request will emit 'abort', while
ServerHttp2Response would do nothing
See: https://github.com/nodejs/node/issues/14963
PR-URL: https://github.com/nodejs/node/pull/14991
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Node.js exposes `console.group()` and `console.groupEnd()` via the
inspector. These functions have no apparent effect when called from
Node.js without the inspector. We cannot easily hide them when Node.js
is started without the inspector because we support opening the
inspector during runtime via `inspector.port()`.
Implement a minimal `console.group()`/`console.groupEnd()`. More
sophisticated implementations are possible, but they can be done in
userland and/or features can be added to this at a later time.
`console.groupCollapsed()` is implemented as an alias for
`console.group()`.
PR-URL: https://github.com/nodejs/node/pull/14910
Fixes: https://github.com/nodejs/node/issues/1716
Ref: https://github.com/nodejs/node/issues/12675
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.
```js
const { performance } = require('perf_hooks');
performance.mark('A');
setTimeout(() => {
performance.mark('B');
performance.measure('A to B', 'A', 'B');
const entry = performance.getEntriesByName('A to B', 'measure')[0];
console.log(entry.duration);
}, 10000);
```
The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.
The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).
Documentation and a test are provided.
PR-URL: https://github.com/nodejs/node/pull/14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
* ensure that UV_... props are constants
* improve error message ... the error message when passing
in `err >= 0` to `util._errnoException()` was less than
useful.
* refine uses of process.binding('uv')
PR-URL: https://github.com/nodejs/node/pull/14933
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Implement a special async_hooks listener that forwards information
about async tasks to V8Inspector asyncTask* API, thus enabling
DevTools feature "async stack traces".
The feature is enabled only on 64bit platforms due to a technical
limitation of V8 Inspector: inspector uses a pointer as a task id,
while async_hooks use 64bit numbers as ids.
To avoid performance penalty of async_hooks when not debugging,
the new listener is enabled only when the process enters a debug mode:
- When the process is started with `--inspect` or `--inspect-brk`,
the listener is enabled immediately and async stack traces
lead all the way to the first tick of the event loop.
- When the debug mode is enabled via SIGUSR1 or `_debugProcess()`,
the listener is enabled together with the debugger. As a result,
only async operations started after the signal was received
will be correctly observed and reported to V8 Inspector. For example,
a `setInterval()` called in the first tick of the event will not be
shown in the async stack trace when the callback is invoked. This
behaviour is consistent with Chrome DevTools.
Last but not least, this commit fixes handling of InspectorAgent's
internal property `enabled_` to ensure it's set back to `false`
after the debugger is deactivated (typically via `process._debugEnd()`).
Fixes: https://github.com/nodejs/node/issues/11370
PR-URL: https://github.com/nodejs/node/pull/13870
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Anna Henningsen <anna@addaleax.net>
The global `process` object had its prototype replaced with a
fresh object that had `EventEmitter.prototype` as its prototype.
With this change, the original `process.constructor.prototype` is
modified to have `EventEmitter.prototype` as its prototype, reflecting
that `process` objects are also `EventEmitter`s.
Fixes: https://github.com/nodejs/node/issues/14699
PR-URL: https://github.com/nodejs/node/pull/14715
Reviewed-By: Anna Henningsen <anna@addaleax.net>
* id values of -1 are allowed. They indicate that the id was never
correctly assigned to the async resource. These will appear in any
call graph, and will only be apparent to those using the async_hooks
module, then reported in an issue.
* ids < -1 are still not allowed and will cause the application to
exit the process; because there is no scenario where this should ever
happen.
* Add asyncId range checks to emitAfterScript().
* Fix emitBeforeScript() range checks which should have been || not &&.
* Replace errors with entries in internal/errors.
* Fix async_hooks tests that check for exceptions to match new
internal/errors entries.
NOTE: emit{Before,After,Destroy}() must continue to exit the process
because in the case of an exception during hook execution the state of
the application is unknowable. For example, an exception could cause a
memory leak:
const id_map = new Map();
before(id) {
id_map.set(id, /* data object or similar */);
},
after(id) {
throw new Error('id never dies!');
id_map.delete(id);
}
Allowing a recoverable exception may also cause an abort because of a
stack check in Environment::AsyncHooks::pop_ids() that verifies the
async id and pop'd ids match. This case would be more difficult to debug
than if fatalError() (lib/async_hooks.js) was called immediately.
try {
async_hooks.emitBefore(null, NaN);
} catch (e) { }
// do something
async_hooks.emitAfter(5);
It also allows an edge case where emitBefore() could be called twice and
not have the pop_ids() CHECK fail:
try {
async_hooks.emitBefore(5, NaN);
} catch (e) { }
async_hooks.emitBefore(5);
// do something
async_hooks.emitAfter(5);
There is the option of allowing mismatches in the stack and ignoring the
check if no async hooks are enabled, but I don't believe going this far
is necessary.
PR-URL: https://github.com/nodejs/node/pull/14722
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
* Reword several of the comments to be more descriptive.
* Rename functions to better indicate what they are doing.
* Change AsyncHooks::uid_fields_ to be a fixed array instead of a
pointer.
* Define regex early so line ends before 80 columns.
* Remove obsolete comments.
* Rename AsyncHooks::InitScope::uid_fields_ to uid_fields_ptr_ because
using the same name as AsyncHooks::uid_fields_ was confusing.
* Place variables that are used to store the new set of hooks if another
hook is enabled/disabled during hook execution into an object to act
as a namespace.
PR-URL: https://github.com/nodejs/node/pull/14722
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Anatoli Papirovski