Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 12 additions & 4 deletions sections/errorhandling/catchunhandledpromiserejection.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,11 @@

### One Paragraph Explainer

Typically, most of modern Node.js/Express application code runs within promises – whether within the .then handler, a function callback or in a catch block. Surprisingly, unless a developer remembered to add a .catch clause, errors thrown at these places are not handled by the uncaughtException event-handler and disappear. Recent versions of Node added a warning message when an unhandled rejection pops, though this might help to notice when things go wrong but it's obviously not a proper error handling method. The straightforward solution is to never forget adding .catch clauses within each promise chain call and redirect to a centralized error handler. However, building your error handling strategy only on developer’s discipline is somewhat fragile. Consequently, it’s highly recommended using a graceful fallback and subscribe to `process.on('unhandledRejection', callback)` – this will ensure that any promise error, if not handled locally, will get its treatment.
Typically, most of modern Node.js/Express application code runs within promises – whether within the .then handler, a function callback or in a catch block. Surprisingly, unless a developer remembered to add a .catch clause, errors thrown at these places are not handled by the uncaughtException event-handler. **Since Node.js 15, unhandled promise rejections crash the process with exit code 1 by default** — they no longer disappear silently. The straightforward solution is to never forget adding .catch clauses within each promise chain call and redirect to a centralized error handler. However, building your error handling strategy only on developer's discipline is somewhat fragile. Consequently, it's highly recommended to also subscribe to `process.on('unhandledRejection', callback)` – this will ensure that any promise error, if not handled locally, will get its treatment before the process exits.

> **Node.js version behavior:**
> - **Node.js < 15**: Unhandled rejections print a `DeprecationWarning (DEP0018)` but the process continues running.
> - **Node.js 15+**: Unhandled rejections **crash the process** with exit code 1 (same behavior as uncaught exceptions).

<br/><br/>

Expand Down Expand Up @@ -40,6 +44,7 @@ process.on('uncaughtException', (error) => {
process.exit(1);
});
```

</details>

<details>
Expand All @@ -60,15 +65,16 @@ process.on('uncaughtException', (error: Error) => {
process.exit(1);
});
```

</details>

<br/><br/>

### Blog Quote: "If you can make a mistake, at some point you will"

From the blog James Nelson
From the blog James Nelson

> Lets test your understanding. Which of the following would you expect to print an error to the console?
> Let's test your understanding. Which of the following would you expect to print an error to the console?

```javascript
Promise.resolve('promised value').then(() => {
Expand All @@ -84,4 +90,6 @@ new Promise((resolve, reject) => {
});
```

> I don’t know about you, but my answer is that I’d expect all of them to print an error. However, the reality is that a number of modern JavaScript environments won’t print errors for any of them.The problem with being human is that if you can make a mistake, at some point you will. Keeping this in mind, it seems obvious that we should design things in such a way that mistakes hurt as little as possible, and that means handling errors by default, not discarding them.
> I don't know about you, but my answer is that I'd expect all of them to print an error. However, the reality is that a number of modern JavaScript environments won't print errors for any of them. The problem with being human is that if you can make a mistake, at some point you will. Keeping this in mind, it seems obvious that we should design things in such a way that mistakes hurt as little as possible, and that means handling errors by default, not discarding them.

> **Note:** As of Node.js 15+, this behavior has changed — unhandled rejections in Node.js will now crash the process with exit code 1. The above quote remains relevant for browser environments and older Node.js versions.