@ -7,12 +7,13 @@ It is an instance of [`EventEmitter`][].
## Event: 'beforeExit'
## Event: 'beforeExit'
This event is emitted when Node.js empties its event loop and has nothing else to
This event is emitted when Node.js empties its event loop and has nothing else
schedule. Normally, Node.js exits when there is no work scheduled, but a listener
to schedule. Normally, Node.js exits when there is no work scheduled, but a
for `'beforeExit'` can make asynchronous calls, and cause Node.js to continue.
listener for `'beforeExit'` can make asynchronous calls, and cause Node.js to
continue.
`'beforeExit'` is not emitted for conditions causing explicit termination, such as
`'beforeExit'` is not emitted for conditions causing explicit termination, such
[`process.exit()`][] or uncaught exceptions, and should not be used as an
as [`process.exit()`][] or uncaught exceptions, and should not be used as an
alternative to the `'exit'` event unless the intention is to schedule more work.
alternative to the `'exit'` event unless the intention is to schedule more work.
## Event: 'exit'
## Event: 'exit'
@ -91,11 +92,12 @@ indefinitely) or upon process exit (more convenient for scripts).
## Event: 'uncaughtException'
## Event: 'uncaughtException'
Emitted when an exception bubbles all the way back to the event loop. If a
The `'uncaughtException'` event is emitted when an exception bubbles all the
listener is added for this exception, the default action (which is to print
way back to the event loop. By default, Node.js handles such exceptions by
a stack trace and exit) will not occur.
printing the stack trace to stderr and exiting. Adding a handler for the
`'uncaughtException'` event overrides this default behavior.
Example of listening for `'uncaughtException'` :
For example :
```js
```js
process.on('uncaughtException', (err) => {
process.on('uncaughtException', (err) => {
@ -111,26 +113,27 @@ nonexistentFunc();
console.log('This will not run.');
console.log('This will not run.');
```
```
Note that `'uncaughtException'` is a very crude mechanism for exception
### Warning: Using `'uncaughtException'` correctly
handling.
Do *not* use it as the Node.js equivalent of `On Error Resume Next` . An
Note that `'uncaughtException'` is a crude mechanism for exception handling
unhandled exception means your application - and by extension Node.js itself -
intended to be used only as a last resort. The event *should not* be used as
is in an undefined state. Blindly resuming means *anything* could happen.
an equivalent to `On Error Resume Next` . Unhandled exceptions inherently mean
that an application is in an undefined state. Attempting to resume application
code without properly recovering from the exception can cause additional
unforeseen and unpredictable issues.
Exceptions thrown from within the event handler will not be caught. Instead the
Exceptions thrown from within the event handler will not be caught. Instead the
process will exit with a non zero exit code and the stack trace will be printed.
process will exit with a non zero exit code and the stack trace will be printed.
This is to avoid infinite recursion.
This is to avoid infinite recursion.
Think of resuming as pulling the power cord when you are upgrading your system.
Attempting to resume normally after an uncaught exception can be similar to
Nine out of ten times nothing happens - but the 10th time, your system is bust.
pulling out of the power cord when upgrading a computer -- nine out of ten
times nothing happens - but the 10th time, the system becomes corrupted.
`'uncaughtException'` should be used to perform synchronous cleanup before
The correct use of `'uncaughtException'` is to perform synchronous cleanup
shutting down the process. It is not safe to resume normal operation after
of allocated resources (e.g. file descriptors, handles, etc) before shutting
`'uncaughtException'` . If you do use it, restart your application after every
down the process. It is not safe to resume normal operation after
unhandled exception!
`'uncaughtException'` .
You have been warned.
## Event: 'unhandledRejection'
## Event: 'unhandledRejection'
@ -142,8 +145,8 @@ a promise chain. This event is useful for detecting and keeping track of
promises that were rejected whose rejections were not handled yet. This event
promises that were rejected whose rejections were not handled yet. This event
is emitted with the following arguments:
is emitted with the following arguments:
- `reason` the object with which the promise was rejected (usually an [`Error`][]
- `reason` the object with which the promise was rejected (usually an
instance).
[`Error`][] instance).
- `p` the promise that was rejected.
- `p` the promise that was rejected.
Here is an example that logs every unhandled rejection to the console
Here is an example that logs every unhandled rejection to the console
@ -254,10 +257,10 @@ Note:
- `SIGUSR1` is reserved by Node.js to start the debugger. It's possible to
- `SIGUSR1` is reserved by Node.js to start the debugger. It's possible to
install a listener but that won't stop the debugger from starting.
install a listener but that won't stop the debugger from starting.
- `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that resets
- `SIGTERM` and `SIGINT` have default handlers on non-Windows platforms that
the terminal mode before exiting with code `128 + signal number` . If one of
resets the terminal mode before exiting with code `128 + signal number` . If
these signals has a listener installed, its default behavior will be removed
one of these signals has a listener installed, its default behavior will be
(Node.js will no longer exit).
removed (Node.js will no longer exit).
- `SIGPIPE` is ignored by default. It can have a listener installed.
- `SIGPIPE` is ignored by default. It can have a listener installed.
- `SIGHUP` is generated on Windows when the console window is closed, and on other
- `SIGHUP` is generated on Windows when the console window is closed, and on other
platforms under various similar conditions, see signal(7). It can have a
platforms under various similar conditions, see signal(7). It can have a
@ -269,11 +272,12 @@ Note:
- `SIGINT` from the terminal is supported on all platforms, and can usually be
- `SIGINT` from the terminal is supported on all platforms, and can usually be
generated with `CTRL+C` (though this may be configurable). It is not generated
generated with `CTRL+C` (though this may be configurable). It is not generated
when terminal raw mode is enabled.
when terminal raw mode is enabled.
- `SIGBREAK` is delivered on Windows when `CTRL+BREAK` is pressed, on non-Windows
- `SIGBREAK` is delivered on Windows when `CTRL+BREAK` is pressed, on
non-Windows
platforms it can be listened on, but there is no way to send or generate it.
platforms it can be listened on, but there is no way to send or generate it.
- `SIGWINCH` is delivered when the console has been resized. On Windows, this will
- `SIGWINCH` is delivered when the console has been resized. On Windows, this
only happen on write to the console when the cursor is being moved, or when a
will only happen on write to the console when the cursor is being moved, or
readable tty is used in raw mode.
when a readable tty is used in raw mode.
- `SIGKILL` cannot have a listener installed, it will unconditionally terminate
- `SIGKILL` cannot have a listener installed, it will unconditionally terminate
Node.js on all platforms.
Node.js on all platforms.
- `SIGSTOP` cannot have a listener installed.
- `SIGSTOP` cannot have a listener installed.