Loading...
Loading...
Browse 7 real-world technical and behavioral interview questions about Error handling. Review scenarios, edge cases, and architectural best practices.
An unhandled promise rejection in Node.js means a promise failed before any code observed the error. Treat it as a bug, await or return the promise chain, and make the process-level handler a last-resort alarm.
ERR_HTTP_HEADERS_SENT means an Express route tried to set status or headers after the response had already been sent. The usual cause is two response paths: missing return after res.send, async callbacks racing, or an error handler trying to respond after headers are committed.
Treat errors as published contract: an HTTP status that classifies the failure, a stable machine-readable code the client branches on, a human message that carries no internal detail, per-field detail for validation, and an explicit statement of whether a retry is safe.
An Express error handler is skipped when it is not registered after routes, lacks the four-argument signature, or an async error never reaches next(). Express 4 needs explicit next(err) for rejected promises; Express 5 forwards them automatically.
A Go interface is non-nil when it holds a concrete type, even if the concrete pointer value is nil. Returning a typed nil pointer as an error creates an interface value that fails err == nil checks.
Middleware runs in registration order, so ordering is behaviour rather than style: the request id precedes logging, the body parser precedes anything reading the body, authentication precedes authorisation, and the error handler goes last because Express only searches forward from the failure.
Streaming commits you to the response before you have seen it: the status code is already sent, any check that needs the whole output now runs after the user has read part of it, a mid-stream failure has no clean retry, and an abandoned tab keeps generating tokens you pay for. It also connects llm serving to the point an interviewer is testing.