Promise .catch(): Handling Rejections

.catch() is the try...catch for promises, intercepting errors (rejections) in a chain. Use it at the end of a promise chain to handle failures from preceding steps, like a failed API call. The footgun: placing it mid-chain can swallow errors.
Why it exists
Synchronous code uses try...catch to handle runtime errors. Asynchronous operations using promises execute outside the initial call stack, so a standard try...catch block around the entire chain won't catch failures that happen later. .catch() provides the mechanism to handle these asynchronous rejections.
The mental model
.catch() is the try...catch equivalent for promise chains. It's a specialized .then() block designed only to execute when a promise is rejected. It acts as a safety net, catching any rejection from any preceding promise in the chain, preventing unhandled promise rejections.
How it works
The .catch(onRejected) method is syntactic sugar for .then(null, onRejected). When a promise in a chain rejects, JavaScript skips all subsequent .then() success handlers and looks for the next rejection handler, which is typically a .catch() block. The function inside .catch() receives the rejection reason (usually an Error object) as its argument. Crucially, .catch() itself returns a new promise. This new promise resolves with the return value of your error handler, allowing the chain to recover. If your handler throws or re-throws an error, the new promise rejects.
When to use it
Use .catch() at the end of any promise chain to create a single, centralized error handling point. This is perfect for logging errors, showing a user-facing error message, or performing cleanup after a failed sequence of async operations like multiple API calls.
When not to use it
Avoid using .catch() in the middle of a chain unless you have a specific recovery strategy, like trying a fallback API or returning a cached value. If you just log the error mid-chain, the promise returned by .catch() will be fulfilled, and subsequent .then() blocks will execute as if everything succeeded, often with missing data, leading to confusing bugs.
One canonical example
Consider fetching user data and parsing it as JSON. The chain is fetch().then().then().catch(). If the network request fails, the first .then is skipped. If the response is not 'ok' and you throw an error, the second .then is skipped. If parsing the JSON fails, the error is also caught. The single .catch at the end handles any of these failure modes:
fetch('/api/user/123')
.then(response => { if (!response.ok) { throw new Error('Network error'); } return response.json(); })
.then(user => console.log(user.name))
.catch(error => console.error('Failed to fetch user:', error));Interview question
What is the primary risk of placing a .catch() block in the middle of a promise chain without implementing a specific recovery strategy?
- a.It makes the entire promise chain synchronous, negating the performance benefits of asynchronous operations.
- b.It can lead to subsequent .then() blocks executing with potentially invalid or missing data, as if the error never occurred.Correct
- c.It prevents any further .catch() blocks from being able to handle errors later in the chain.
- d.It will automatically re-throw the error, forcing all subsequent .then() blocks to be skipped.
Why? this is the answer
The card states that if a .catch() block mid-chain only logs an error without recovery, the promise it returns will be fulfilled, causing subsequent .then() blocks to execute as if successful, potentially leading to 'confusing bugs' with 'missing data'. Option D is incorrect because .catch() resolves by default unless an error is explicitly re-thrown.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #javascript
- #promises
- #asynchronous
- #error handling
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on javascript — each one lists the topics its interview covers.
See open roles