UnhandledPromiseRejectionWarning / Uncaught (in promise) (tested)

A rejected Promise with no .catch() or surrounding try/catch is an unhandled promise rejection. Old Node.js printed a warning and kept running. We tested current Node and current headless Chromium side by side to see what actually happens now.

1. The two different behaviours, measured

We ran the same bug — Promise.reject(new Error(...)) with nothing attached to it — in Node.js 24.21.0 and in headless Chromium 153 (via Playwright). The outcomes are not the same.

2. Node.js: it crashes, and the old warning text is gone

We ran this file with nothing else in it:

Promise.reject(new Error("boom - no handler"));
console.log("this line still runs synchronously");

Exact output on Node.js 24.21.0:

this line still runs synchronously
file:///tmp/unhandledrej-guide/node_crash.mjs:1
Promise.reject(new Error("boom - no handler"));
               ^

Error: boom - no handler
    at file:///tmp/unhandledrej-guide/node_crash.mjs:1:16
    at ModuleJob.run (node:internal/modules/esm/module_job:561:25)
    ...

Node.js v24.21.0

Exit code was 1. Note what is not there: there is no line starting with UnhandledPromiseRejectionWarning. That text was the behaviour in old Node (≤ 14, before the default flipped). Current Node prints the error like an uncaught exception and kills the process outright. If you still see "UnhandledPromiseRejectionWarning" in your logs, you are on an old Node version or reading an old stack trace saved somewhere — it is not what current Node prints.

3. The common real cause: a floating promise

You rarely write Promise.reject() directly. The usual way to hit this is forgetting to return or await a promise, or chaining .then() without a paired .catch():

async function fetchThing() {
  throw new Error("fetch failed inside async fn");
}

function run() {
  // BUG: no return, no await, no .catch()
  fetchThing().then(r => console.log("got", r));
}

run();

We ran this on Node.js 24.21.0. run() returns immediately (synchronous code finishes fine), but when the rejected promise from fetchThing() is checked on the next microtask turn with no .catch() attached, Node prints the same style of error and stack pointing at the throw site, then exits with code 1. The fix is any one of: await fetchThing() inside an async function wrapped in try/catch, return fetchThing()... so the caller's chain handles it, or adding .catch(err => ...) to the chain itself.

4. Fix #1: a .catch() or try/catch

// Promise chain
fetchThing().then(r => console.log(r)).catch(err => console.error("failed:", err.message));

// async/await
async function run() {
  try {
    const r = await fetchThing();
    console.log(r);
  } catch (err) {
    console.error("failed:", err.message);
  }
}

This is the real fix: handle the rejection where it happens. The global handlers below are a safety net, not a substitute.

5. Fix #2 (Node): a global process.on('unhandledRejection') handler

We added this one line before the same Promise.reject() call:

process.on("unhandledRejection", (reason, promise) => {
  console.log("CAUGHT by unhandledRejection handler:", reason.message);
});
Promise.reject(new Error("boom - no handler"));

Measured result: Node printed CAUGHT by unhandledRejection handler: boom - no handler, the rest of the script kept running (a later setTimeout still fired), and the process exited with code 0. The crash is fully suppressed. Treat this as a last-resort logger/reporter (e.g. send to your error tracker), not a way to silently ignore bugs — per the Node.js docs, relying on it instead of fixing the rejection is explicitly discouraged.

6. Fix #2 (browser): window.addEventListener('unhandledrejection', ...)

In headless Chromium 153 we confirmed the rejection fires a real DOM event with the reason attached:

window.addEventListener("unhandledrejection", ev => {
  console.log("reason:", ev.reason);
});
Promise.reject(new Error("boom in browser - no handler"));

Measured: the unhandledrejection event fired with ev.reason set to the Error object, and Playwright's page also reported a pageerror with message "boom in browser - no handler" (this is what shows as Uncaught (in promise) Error: boom in browser - no handler in a real DevTools console). The page kept running fine afterward — a follow-up 1 + 1 evaluation on the same page still returned 2. Calling ev.preventDefault() inside the listener measurably suppressed that console error entirely in our test: with preventDefault() called, no pageerror fired at all.

7. Node vs browser, side by side

8. Checklist

• Every async function call you don't await or return is a candidate for an unhandled rejection. Grep for .then( calls with no .catch( on the same chain.
• Add a global process.on("unhandledRejection", ...) in Node and a window.addEventListener("unhandledrejection", ...) in the browser as a safety net that logs to your error tracker — we confirmed both actually fire and both can suppress the default crash/log.
• Don't use the global handler to silence the warning and move on. Fix the actual missing .catch(); we reproduced the exact same crash from a realistic "floating .then()" bug, not just a bare Promise.reject().
• If your logs mention UnhandledPromiseRejectionWarning, that string is from old Node (≤14). Current Node (we tested 24.21.0) prints a plain error and stack trace instead and exits immediately — check your Node version with node --version.

If your actual crash is a different runtime error, see PlainHeaders for inspecting what your server sends when a request handler throws.

Written with AI assistance. Measured on 2026-10-02 with Node.js 24.21.0 and headless Chromium 153 via Playwright 1.63. Ran a rejected promise with no handler, a floating .then() with no .catch(), and both global-handler fixes, and recorded the exact exit codes and printed text. PlainHeaders is our extension; Node.js and Chromium are free.