Previously the enhancement were done right after emitting
`'uncaughtException'`, which meant by the time we knew the
exception was fatal in C++, the error.stack had already been
patched.
This patch moves those routines to be called later during the
fatal exception handling, and split them into two stages:
before and after the inspector is notified by the invocation of
`V8Inspector::exceptionThrown`. We now expand the stack to include
additional informations about unhandled 'error' events before
the inspector is notified, but delay the highlighting of the
frames until after the inspector is notified, so that the
ANSI escape sequences won't show up in the inspector console.
PR-URL: https://github.com/nodejs/node/pull/28308
Fixes: https://github.com/nodejs/node/issues/28287
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
The C++ land `node::FatalException()` is not in fact fatal anymore.
It gives the user a chance to handle the uncaught exception
globally by listening to the `uncaughtException` event. This patch
renames it to `TriggerUncaughtException` in C++ to avoid the confusion.
In addition rename the JS land handler to `onGlobalUncaughtException`
to reflect its purpose - we have to keep the alias
`process._fatalException` and use that for now since it has been
monkey-patchable in the user land.
This patch also
- Adds more comments to the global uncaught exception handling routine
- Puts a few other C++ error handling functions into the `errors`
namespace
- Moves error-handling-related bindings to the `errors` binding.
Refs: 2b252acea4
PR-URL: https://github.com/nodejs/node/pull/28257
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
This makes sure that errors that shut down the application are
inspected with `util.inspect()`. That makes sure that all extra
properties on the error will be visible and also that the stack trace
is highlighted (Node.js internal frames will be grey and node modules
are underlined).
PR-URL: https://github.com/nodejs/node/pull/27243
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Previously, we call the JS land `runNextTicks` implementation
immediately from JS land after evaluating the main module or the
input, so these synchronous JS call frames would show up in the stack
trace of the async errors, which can be confusing. This patch moves
those calls into C++ so that more of these internal scheduler
implementation details can be hidden and the users can see a cleaner
a cleaner async JS stack trace.
PR-URL: https://github.com/nodejs/node/pull/27392
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
This patch adds an internal function that prints to stdout or
stderr by directly writing to the known file descriptor, and
uses it internally in common cases to avoid the overhead
of the console implementation.
PR-URL: https://github.com/nodejs/node/pull/27320
Reviewed-By: James M Snell <jasnell@gmail.com>
This patch reduce usage of `process._breakFirstLine` and
`process._eval` in the internals and use
`getOptionValue('--inspect-brk')` and `getOptionValue('--eval')`
instead wherever possible.
PR-URL: https://github.com/nodejs/node/pull/27278
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
In addition, use process.stderr instead of console.error when
there is no need to swallow the error.
PR-URL: https://github.com/nodejs/node/pull/27112
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This adds a flag to define the default behavior for unhandled
rejections. Three modes exist: `none`, `warn` and `strict`. The first
is going to silence all unhandled rejection warnings. The second
behaves identical to the current default with the excetion that no
deprecation warning will be printed and the last is going to throw
an error for each unhandled rejection, just as regular exceptions do.
It is possible to intercept those with the `uncaughtException` hook
as with all other exceptions as well.
This PR has no influence on the existing `unhandledRejection` hook.
If that is used, it will continue to function as before.
PR-URL: https://github.com/nodejs/node/pull/26599
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Use the "no-restricted-globals" ESLint rule to lint for it.
PR-URL: https://github.com/nodejs/node/pull/27027
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This PR updates the current `--experimental-modules` implementation
based on the work of the modules team and reflects Phase 2 of our
new modules plan.
The largest differences from the current implementation include
* `packge.type` which can be either `module` or `commonjs`
- `type: "commonjs"`:
- `.js` is parsed as commonjs
- default for entry point without an extension is commonjs
- `type: "module"`:
- `.js` is parsed as esm
- does not support loading JSON or Native Module by default
- default for entry point without an extension is esm
* `--entry-type=[mode]`
- allows you set the type on entry point.
* A new file extension `.cjs`.
- this is specifically to support importing commonjs in the
`module` mode.
- this is only in the esm loader, the commonjs loader remains
untouched, but the extension will work in the old loader if you use
the full file path.
* `--es-module-specifier-resolution=[type]`
- options are `explicit` (default) and `node`
- by default our loader will not allow for optional extensions in
the import, the path for a module must include the extension if
there is one
- by default our loader will not allow for importing directories that
have an index file
- developers can use `--es-module-specifier-resolution=node` to
enable the commonjs specifier resolution algorithm
- This is not a “feature” but rather an implementation for
experimentation. It is expected to change before the flag is
removed
* `--experimental-json-loader`
- the only way to import json when `"type": "module"`
- when enable all `import 'thing.json'` will go through the
experimental loader independent of mode
- based on https://github.com/whatwg/html/issues/4315
* You can use `package.main` to set an entry point for a module
- the file extensions used in main will be resolved based on the
`type` of the module
Refs: https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal
Refs: https://github.com/nodejs/modules/pull/180
Refs: https://github.com/nodejs/ecmascript-modules/pull/6
Refs: https://github.com/nodejs/ecmascript-modules/pull/12
Refs: https://github.com/nodejs/ecmascript-modules/pull/28
Refs: https://github.com/nodejs/modules/issues/255
Refs: https://github.com/whatwg/html/issues/4315
Refs: https://github.com/w3c/webcomponents/issues/770
Co-authored-by: Myles Borins <MylesBorins@google.com>
Co-authored-by: John-David Dalton <john.david.dalton@gmail.com>
Co-authored-by: Evan Plaice <evanplaice@gmail.com>
Co-authored-by: Geoffrey Booth <webmaster@geoffreybooth.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/26745
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
writeReport() is more descriptive of what the function does.
PR-URL: https://github.com/nodejs/node/pull/26527
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit removes process.report.setOptions(). Instead of
using complex configuration synchronization between C++ and
JS, this commit introduces individual getters and setters.
PR-URL: https://github.com/nodejs/node/pull/26414
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Wyatt Preul <wpreul@gmail.com>
This commit uses the triggerReport() binding to handle
uncaught exceptions and removes the custom onUncaughtException
function.
PR-URL: https://github.com/nodejs/node/pull/26386
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This commit completes the renaming of node-report to report
in order to better differentiate core's reporting from the
node-report npm module.
PR-URL: https://github.com/nodejs/node/pull/26371
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Report the actual source code when running with `--eval` and
`--inspect-brk`, by telling the vm module to break on the
first line of the script being executed rather than wrapping
the source code in a function.
PR-URL: https://github.com/nodejs/node/pull/25832
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This commit combines two if statements into a single if
statement. Another if statement is replaced with a ternary.
PR-URL: https://github.com/nodejs/node/pull/25744
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This patch splits the execution mode selection from the environment
setup in `lib/internal/bootstrap/node.js`, and split the entry point
of different execution mode into main scripts under
`lib/internal/main`:
- `check_syntax.js`: used when `-c`/`--check` which only checks the
syntax of the input instead of executing it.
- `eval_stdin.js`: used when `-e` is passed without value and stdin
is not a TTY (e.g. something is piped).
- `eval_string`: used when `-e` is passed along with a string argument
- `inspect.js`: for `node inspect`/`node debug`
- `print_bash_completion.js`: for `--completion-bash`
- `print_help.js`: for `--help`
- `prof_process.js`: for `--prof-process`
- `repl.js`: for the REPL
- `run_main_module.js`: used when a main module is passed
- `run_third_party_main.js`: for the legacy `_third_party_main.js`
support
- `worker_thread.js`: for workers
This makes the entry points easier to navigate and paves the way
for customized v8 snapshots (that do not need to deserialize
execution mode setup) and better embedder APIs.
As an example, after this patch, for the most common case where
Node.js executes a user module as an entry point, it essentially
goes through:
- `lib/internal/per_context.js` to setup the v8 Context (which is
also run when setting up contexts for the `vm` module)
- `lib/internal/bootstrap/loaders.js` to set up internal binding
and builtin module loaders (that are separate from the loaders
accessible in the user land).
- `lib/internal/bootstrap/node.js`: to set up the rest of the
environment, including various globals and the process object
- `lib/internal/main/run_main_module.js`: which is selected from
C++ to prepare execution of the user module.
This patch also removes `NativeModuleLoader::CompileAndCall` and
exposes `NativeModuleLoader::LookupAndCompile` directly so that
we can handle syntax errors and runtime errors of bootstrap
scripts differently.
PR-URL: https://github.com/nodejs/node/pull/25667
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Make node-report part of core runtime because:
1. When enabled, node-report significantly helps root cause various
types of problems, including support issues sent to the various repos
of the Node.js organization.
2. The requirement of explicitly adding the dependency to node-report
in user applications often represents a blocker to adoption.
Major deviation from the module version of the node-report is that the
report is generated in JSON format, as opposed to human readable text.
No new functionalities have been added, changes that are required for
melding it as a built-in capability has been affected on the module
version of node-report (https://github.com/nodejs/node-report)
Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com>
Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com>
Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Co-authored-by: Julian Alimin <dmastag@yahoo.com>
Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com>
Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com>
Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com>
Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Co-authored-by: Richard Lau <riclau@uk.ibm.com>
Co-authored-by: Sam Roberts <vieuxtech@gmail.com>
Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/22712
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
This patch:
- Moves `tryGetCwd`, `evalScript` and `fatalException` from
`bootstrap/node.js` into `process/execution.js` so that
they do have to be passed into the worker thread
setup function, instead the worker code can require them
when necessary.
- Moves `setUncaughtExceptionCaptureCallback` and
`hasUncaughtExceptionCaptureCallback` along with the two
global state `exceptionHandlerState` and
`shouldAbortOnUncaughtToggle` info `process.execution.js`
as those are only used by the fatalException and these
two accessors as one self-contained unit.
PR-URL: https://github.com/nodejs/node/pull/25199
Reviewed-By: James M Snell <jasnell@gmail.com>
