Errors need an owner capable of deciding recovery. Promise rejections, callbacks and emitted error events have different propagation paths.
Before you start
You should know JavaScript promises, asynchronous errors and the distinction between a process and a request. When following a server example, identify the resource owner and the point where work completes. Try experiments locally with bounded input instead of assuming production traffic behaves like a single request.
The practical goal is to reason through this situation: Await a repository call inside the request handler’s error boundary. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Find the actual completion
A started promise can reject after the surrounding synchronous try block has already finished.
Step 2: Await inside its owner
Put awaited work in the request’s try/catch when that request can still choose a response.
Step 3: Own background failures separately
Attach rejection handling and cancellation to detached jobs; they cannot report through an already-completed response.
Worked scenario
Await a repository call inside the request handler’s error boundary.
async function loadRecord(repository, id) {
try {
return await repository.load(id);
} catch (error) {
throw new Error('Unable to load record', { cause: error });
}
}Repository and id are application-provided. Emitted stream error events require their own appropriate handling; await does not intercept unrelated event emissions automatically.
Common mistake
A try block around starting a promise does not catch its later rejection.
Verify the behavior
Reject before and after an asynchronous boundary. Verify each operation has one intentional recovery or escalation path.
Interview exercise
Catch a background task failure.
Answer and reasoning
Attach an explicit rejection handler and define retries, logging and cancellation independently from an already completed request.
Continue learning
Compare the scenario with the Node.js interview questions and test your understanding with the Node.js MCQs. For terminology and implementation details, consult the reference material.