Comparing the three async error-handling styles

WHAT THIS TESTS This assesses whether you understand the evolution of async error handling and the specific failure modes of each style, especially the danger of dropped rejections.

A GOOD ANSWER COVERS The error-first callback convention is the original Node pattern: every callback receives an error as its first parameter, so you must check it explicitly at each step, which leads to nesting and easy-to-miss checks. Promise chains improve this by letting errors propagate down the chain to a single catch, so one handler can cover many steps, and a throw anywhere in a then becomes a rejection. async/await is syntactic sugar over Promises that lets you wrap awaited calls in a normal try/catch, giving synchronous-looking control flow and natural stack traces. The crucial pitfall is an unhandled rejection: if a Promise rejects and nothing attaches a catch, Node emits an unhandledRejection event, and in current Node versions the default behavior is to terminate the process, which can crash your server.

COMMON WRONG ANSWERS Thinking try/catch can catch a rejection from a Promise you started but never awaited, believing unhandled rejections are always silently ignored, or mixing callbacks and Promises so errors fall between the cracks. Forgetting that a throw inside a then is captured by a later catch.

LIKELY FOLLOW-UPS How async/await desugars to then and catch, why a non-awaited Promise escapes the surrounding try/catch, how to listen for the unhandledRejection event, and how to promisify callback APIs.

ONE CONCRETE EXAMPLE If you call an async function but forget to await it inside a try block, a rejection from it will not be caught by that try/catch, because the function already returned a pending Promise and execution moved on. The rejection then surfaces as an unhandledRejection. Adding await, or attaching a catch to the returned Promise, routes the error correctly and prevents the process from crashing.