Unhandled Rejections and Floating Promises

## What "floating" means An `async` function always returns a promise. Calling it does two things: it starts running the body synchronously up to the first `await`, and it gives you back a promise object representing the eventual outcome. Whether you keep that object is entirely up to you. A *floating* (or *dangling*) promise is one you discarded — no `await`, no `return`, no `.then()`/`.catch()` attached — so no code anywhere is subscribed to its outcome. While the promise fulfils, nothing bad is visible. The moment it rejects, the rejection has nowhere to go. ## Why try/catch does not help This is the single most common misunderstanding: ```js async function save() { throw new Error('db down'); } try { save(); // no await } catch (err) { console.log('never runs'); } console.log('reached'); ``` An `async` function never throws synchronously — even a `throw` on its first line is converted into a rejected promise. So `save()` returns normally, the `try` block completes, and the `catch` clause is out of scope forever after. Adding `await` reconnects them: `await` on a rejected promise throws the rejection reason at that point in the async function, which is exactly what a surrounding `try/catch` is positioned to see. The same trap appears without `async` at all — `fetchThing().then(use)` with no rejection handler floats the rejection just as thoroughly. ## What the runtime does about it Runtimes track, per promise, whether a rejection handler was ever attached. When a promise rejects and none was, the host is notified: - **In a browser**, the global object fires an `unhandledrejection` event, a `PromiseRejectionEvent` carrying `.promise` and `.reason`. The default action is to report the error to the console; calling `event.preventDefault()` suppresses that report. - **In Node**, the default mode since v15 is `throw`: the rejection is raised as an uncaught exception, printing the reason and terminating the process with a non-zero exit code — unless a `process.on('unhandledRejection', ...)` listener is registered, in which case that listener runs instead. Older Node versions only printed an `UnhandledPromiseRejectionWarning` and kept going, which is why a lot of legacy advice on this topic is now wrong. So "nothing happens" is never the right answer. Either your error is buried in a console log nobody reads, or your server process dies. ## Attaching some handler is not the same as handling rejection ```js fetchUser(id).then(render); // still floating ``` `.then(onFulfilled)` with no second argument does attach to the original promise, but it *forwards* the rejection to the promise it returns — and that derived promise has no handler. The unhandled rejection simply moves to the tail of the chain. The same goes for `.finally()`, which runs its callback and then re-rejects. Only a real rejection handler — `.catch(fn)`, `.then(ok, fail)`, or an `await` inside a `try` — actually consumes the failure. ## The discipline Every promise you create should have an owner. In practice that means one of three things at each call site: 1. **`await` it** — you handle the outcome here, inside a `try/catch` if the failure is recoverable. 2. **`return` it** — you delegate ownership to your caller, who will `await` it. 3. **Deliberately detach it, with a handler** — for genuine fire-and-forget work such as a metrics ping: ```js void recordMetric(event).catch(err => log.warn({ err }, 'metric failed')); ``` The `.catch()` is what turns fire-and-forget into something safe; the `void` operator is only a readability marker saying "the discard is intentional". A useful review heuristic: any expression statement that evaluates to a promise and does nothing with it is a bug until proven otherwise. That is also exactly the rule that async-aware linters encode, and it is why interviewers like this question — the missing `await` is one of the few bugs that both hides errors *and* changes control flow, since the caller races ahead while the work is still in flight.