All 15 Error Handling questions
More in Error Handling
What is the difference between operational errors and programmer errors in Node.js, and why does this distinction matter? How would you create and use custom Error subclasses in a Node.js application to represent different categories of application-specific errors? Why doesn't Express automatically catch errors thrown inside an async route handler in versions prior to Express 5, and how do you work around this? How do you correctly propagate and handle errors from a Node.js stream, given that stream errors aren't caught by a surrounding try/catch? What is the try/catch/finally pattern's 'finally' block used for, and how does it behave with async/await? What is the risk of exposing a raw error's stack trace in an API response, and how do you prevent it while still logging full details server-side? What is the difference between a validation error and a business-logic error, and how might a Node.js application handle each differently? How would you implement a global 'not found' (404) handler in Express for any route that doesn't match a defined endpoint? What is a centralized error-handling middleware pattern in Express, and what advantages does it provide over handling errors in each individual route? What is the difference between a 4xx and 5xx HTTP status code from an error-handling perspective, and how should a Node.js API decide which to return?
Advertisement
Node.js › Error Handling

What is the difference between throwing an error synchronously and calling a callback with an error as its first argument in Node.js?

Beginner

Answer

Synchronous code throws an Error object directly, caught by a surrounding try/catch. Traditional Node.js callback-style asynchronous functions instead follow the 'error-first callback' convention, passing an error (or null if none occurred) as the callback's first argument, since a thrown error inside an async callback executing later couldn't be caught by a try/catch wrapped around the original function call, as that call has already returned by the time the callback runs.
// Synchronous: throw and catch
function parseConfig(json) {
  try { return JSON.parse(json); } catch (err) { throw new Error('Invalid config JSON'); }
}

// Asynchronous callback-style: error-first convention
fs.readFile('config.json', (err, data) => {
  if (err) return console.error('Failed to read config:', err.message);
  console.log(data);
});
Real-world example A developer new to Node.js initially wrapped an fs.readFile call in a try/catch expecting to catch a file-not-found error, only to realize the callback-based API requires checking the err parameter inside the callback itself, since the try/catch around the outer call can't catch an error surfaced asynchronously.

Common follow-ups: Why can't a try/catch around an asynchronous callback-based function call actually catch an error that occurs inside that callback?;How does this same limitation not apply to async/await-based code?

Async Patterns;Core Node.js Modules
All 15 Error Handling questions