The `process` object is a `global` that provides information about, and control

over, the current Node.js process. As a global, it is always available to

Node.js applications without using `require()`. It can also be explicitly

accessed using `require()`:

```js

const process = require('process');

```

## Process Events

The `process` object is an instance of [`EventEmitter`][].

<!-- YAML

added: v0.11.12

-->

The `'beforeExit'` event is emitted when Node.js empties its event loop and has

no additional work to schedule. Normally, the Node.js process will exit when

there is no work scheduled, but a listener registered on the `'beforeExit'`

event can make asynchronous calls, and thereby cause the Node.js process to

The listener callback function is invoked with the value of

[`process.exitCode`][] passed as the only argument.

The `'beforeExit'` event is *not* emitted for conditions causing explicit

termination, such as calling [`process.exit()`][] or uncaught exceptions.

The `'beforeExit'` should *not* be used as an alternative to the `'exit'` event

unless the intention is to schedule additional work.

```js

process.on('beforeExit', (code) => {

console.log('Process beforeExit event with code: ', code);

});

process.on('exit', (code) => {

console.log('Process exit event with code: ', code);

});

console.log('This message is displayed first.');

// Prints:

// This message is displayed first.

// Process beforeExit event with code: 0

// Process exit event with code: 0

```

<!-- YAML

added: v0.7.7

-->

If the Node.js process is spawned with an IPC channel (see the [Child Process][]

and [Cluster][] documentation), the `'disconnect'` event will be emitted when

the IPC channel is closed.

<!-- YAML

added: v0.1.7

-->

* `code` {integer}

The `'exit'` event is emitted when the Node.js process is about to exit as a

result of either:

* The `process.exit()` method being called explicitly;

* The Node.js event loop no longer having any additional work to perform.

There is no way to prevent the exiting of the event loop at this point, and once

all `'exit'` listeners have finished running the Node.js process will terminate.

The listener callback function is invoked with the exit code specified either

by the [`process.exitCode`][] property, or the `exitCode` argument passed to the

```js

process.on('exit', (code) => {

console.log(`About to exit with code: ${code}`);

});

```

Listener functions **must** only perform **synchronous** operations. The Node.js

process will exit immediately after calling the `'exit'` event listeners

causing any additional work still queued in the event loop to be abandoned.

In the following example, for instance, the timeout will never occur:

```js

process.on('exit', (code) => {

setTimeout(() => {

console.log('This will not run');

}, 0);

});

```

<!-- YAML

added: v0.5.10

-->

* `message` { Object | boolean | number | string | null } a parsed JSON object

or a serializable primitive value.

* `sendHandle` {net.Server|net.Socket} a [`net.Server`][] or [`net.Socket`][]

object, or undefined.

If the Node.js process is spawned with an IPC channel (see the [Child Process][]

and [Cluster][] documentation), the `'message'` event is emitted whenever a

message sent by a parent process using [`childprocess.send()`][] is received by

the child process.

The message goes through serialization and parsing. The resulting message might

not be the same as what is originally sent.

If the `serialization` option was set to `advanced` used when spawning the

process, the `message` argument can contain data that JSON is not able

to represent.

See [Advanced Serialization for `child_process`][] for more details.

-->

* `promise` {Promise} The promise that resolved or rejected more than once.

* `value` {any} The value with which the promise was either resolved or

rejected after the original resolve.

The `'multipleResolves'` event is emitted whenever a `Promise` has been either:

* Resolved more than once.

* Rejected more than once.

* Rejected after resolve.

* Resolved after reject.

This is useful for tracking potential errors in an application while using the

`Promise` constructor, as multiple resolutions are silently swallowed. However,

the occurrence of this event does not necessarily indicate an error. For

example, [`Promise.race()`][] can trigger a `'multipleResolves'` event.

```js

process.on('multipleResolves', (type, promise, reason) => {

console.error(type, promise, reason);

setImmediate(() => process.exit(1));

});

async function main() {

try {

return await new Promise((resolve, reject) => {

resolve('First call');

resolve('Swallowed resolve');

reject(new Error('Swallowed reject'));

});

} catch {

throw new Error('Failed');

}

}

main().then(console.log);

// resolve: Promise { 'First call' } 'Swallowed resolve'

// reject: Promise { 'First call' } Error: Swallowed reject

// at Promise (*)

// at new Promise (<anonymous>)

// at main (*)

// First call

```

<!-- YAML

added: v1.4.1

-->

* `promise` {Promise} The late handled promise.

The `'rejectionHandled'` event is emitted whenever a `Promise` has been rejected

and an error handler was attached to it (using [`promise.catch()`][], for

example) later than one turn of the Node.js event loop.

The `Promise` object would have previously been emitted in an

`'unhandledRejection'` event, but during the course of processing gained a

rejection handler.

There is no notion of a top level for a `Promise` chain at which rejections can

always be handled. Being inherently asynchronous in nature, a `Promise`

rejection can be handled at a future point in time — possibly much later than

the event loop turn it takes for the `'unhandledRejection'` event to be emitted.

Another way of stating this is that, unlike in synchronous code where there is

an ever-growing list of unhandled exceptions, with Promises there can be a

growing-and-shrinking list of unhandled rejections.

In synchronous code, the `'uncaughtException'` event is emitted when the list of

unhandled exceptions grows.

In asynchronous code, the `'unhandledRejection'` event is emitted when the list

of unhandled rejections grows, and the `'rejectionHandled'` event is emitted

when the list of unhandled rejections shrinks.

```js

const unhandledRejections = new Map();

process.on('unhandledRejection', (reason, promise) => {

unhandledRejections.set(promise, reason);

process.on('rejectionHandled', (promise) => {

unhandledRejections.delete(promise);

});

```

In this example, the `unhandledRejections` `Map` will grow and shrink over time,

reflecting rejections that start unhandled and then become handled. It is

possible to record such errors in an error log, either periodically (which is

likely best for long-running application) or upon process exit (which is likely

most convenient for scripts).

<!-- YAML

added: v0.1.18

pr-url: https://github.com/nodejs/node/pull/26599

description: Added the `origin` argument.

* `err` {Error} The uncaught exception.

* `origin` {string} Indicates if the exception originates from an unhandled

rejection or from synchronous errors. Can either be `'uncaughtException'` or

`'unhandledRejection'`.

The `'uncaughtException'` event is emitted when an uncaught JavaScript

exception bubbles all the way back to the event loop. By default, Node.js

handles such exceptions by printing the stack trace to `stderr` and exiting

with code 1, overriding any previously set [`process.exitCode`][].

behavior. Alternatively, change the [`process.exitCode`][] in the

`'uncaughtException'` handler which will result in the process exiting with the

provided exit code. Otherwise, in the presence of such handler the process will

process.on('uncaughtException', (err, origin) => {

fs.writeSync(

process.stderr.fd,

`Caught exception: ${err}\n` +

`Exception origin: ${origin}`

);

setTimeout(() => {

console.log('This will still run.');

}, 500);

// Intentionally cause an exception, but don't catch it.

nonexistentFunc();

console.log('This will not run.');

```

It is possible to monitor `'uncaughtException'` events without overriding the

default behavior to exit the process by installing a

`'uncaughtExceptionMonitor'` listener.

intended to be used only as a last resort. The event *should not* be used as

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.

This is to avoid infinite recursion.

pulling out the power cord when upgrading a computer. Nine out of ten

times, nothing happens. But the tenth time, the system becomes corrupted.

The correct use of `'uncaughtException'` is to perform synchronous cleanup

of allocated resources (e.g. file descriptors, handles, etc) before shutting

down the process. **It is not safe to resume normal operation after

`'uncaughtException'`.**

in a separate process to detect application failures and recover or restart as

needed.

### Event: `'uncaughtExceptionMonitor'`

<!-- YAML

-->

* `err` {Error} The uncaught exception.

* `origin` {string} Indicates if the exception originates from an unhandled

rejection or from synchronous errors. Can either be `'uncaughtException'` or

`'unhandledRejection'`.

The `'uncaughtExceptionMonitor'` event is emitted before an

`'uncaughtException'` event is emitted or a hook installed via

[`process.setUncaughtExceptionCaptureCallback()`][] is called.

Installing an `'uncaughtExceptionMonitor'` listener does not change the behavior

once an `'uncaughtException'` event is emitted. The process will

still crash if no `'uncaughtException'` listener is installed.

```js

process.on('uncaughtExceptionMonitor', (err, origin) => {

MyMonitoringTool.logSync(err, origin);

});

// Intentionally cause an exception, but don't catch it.

nonexistentFunc();

// Still crashes Node.js

```

<!-- YAML

added: v1.4.1

changes:

- version: v7.0.0

pr-url: https://github.com/nodejs/node/pull/8217

- version: v6.6.0

pr-url: https://github.com/nodejs/node/pull/8223

* `reason` {Error|any} The object with which the promise was rejected

(typically an [`Error`][] object).

* `promise` {Promise} The rejected promise.

When programming with Promises, exceptions are encapsulated as "rejected

promises". Rejections can be caught and handled using [`promise.catch()`][] and

are propagated through a `Promise` chain. The `'unhandledRejection'` event is

process.on('unhandledRejection', (reason, promise) => {

console.log('Unhandled Rejection at:', promise, 'reason:', reason);

return reportToUser(JSON.pasre(res)); // Note the typo (`pasre`)

}); // No `.catch()` or `.then()`

The following will also trigger the `'unhandledRejection'` event to be

emitted:

```js

function SomeResource() {

// Initially set the loaded status to a rejected promise

this.loaded = Promise.reject(new Error('Resource not yet loaded!'));

}

// no .catch or .then on resource.loaded for at least a turn

```

In this example case, it is possible to track the rejection as a developer error

as would typically be the case for other `'unhandledRejection'` events. To

address such failures, a non-operational

[`.catch(() => { })`][`promise.catch()`] handler may be attached to

`resource.loaded`, which would prevent the `'unhandledRejection'` event from

<!-- YAML

added: v6.0.0

-->

* `warning` {Error} Key properties of the warning are:

* `name` {string} The name of the warning. **Default:** `'Warning'`.

* `message` {string} A system-provided description of the warning.

* `stack` {string} A stack trace to the location in the code where the warning

was issued.

A process warning is similar to an error in that it describes exceptional

conditions that are being brought to the user's attention. However, warnings

are not part of the normal Node.js and JavaScript error handling flow.

Node.js can emit warnings whenever it detects bad coding practices that could

```js

process.on('warning', (warning) => {

console.warn(warning.name); // Print the warning name

console.warn(warning.message); // Print the warning message

console.warn(warning.stack); // Print the stack trace

});

```

By default, Node.js will print process warnings to `stderr`. The `--no-warnings`

command-line option can be used to suppress the default console output but the

`'warning'` event will still be emitted by the `process` object.

The following example illustrates the warning that is printed to `stderr` when

> process.on('foo', () => {});

> process.on('foo', () => {});

> (node:38638) MaxListenersExceededWarning: Possible EventEmitter memory leak

detected. 2 foo listeners added. Use emitter.setMaxListeners() to increase limit

```

In contrast, the following example turns off the default warning output and

adds a custom handler to the `'warning'` event:

> process.on('foo', () => {});

> process.on('foo', () => {});

> Do not do that!

```

The `--trace-warnings` command-line option can be used to have the default

console output for warnings include the full stack trace of the warning.

Launching Node.js using the `--throw-deprecation` command line flag will

cause custom deprecation warnings to be thrown as exceptions.

Using the `--trace-deprecation` command line flag will cause the custom

deprecation to be printed to `stderr` along with the stack trace.

Using the `--no-deprecation` command line flag will suppress all reporting

of the custom deprecation.

The `*-deprecation` command line flags only affect warnings that use the name

#### Emitting custom warnings

See the [`process.emitWarning()`][process_emit_warning] method for issuing

custom or application-specific warnings.

<!--type=event-->

Signals are not available on [`Worker`][] threads.

The signal handler will receive the signal's name (`'SIGINT'`,

`'SIGTERM'`, etc.) as the first argument.

The name of each event will be the uppercase common name for the signal (e.g.

`'SIGINT'` for `SIGINT` signals).

// Using a single function to handle multiple signals

function handle(signal) {

console.log(`Received ${signal}`);

}

process.on('SIGINT', handle);

process.on('SIGTERM', handle);