All 15 Error Handling questions
More in Error Handling
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? 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? What is error wrapping (or error chaining), and how does the Error class's 'cause' property support it in modern Node.js? How would you implement a global error boundary for an entire Node.js application to ensure no error type goes completely unhandled? How would you implement error handling for a GraphQL API in Node.js, given GraphQL's different error-response format compared to REST?
Advertisement
Node.js › Error Handling

What is the difference between a validation error and a business-logic error, and how might a Node.js application handle each differently?

Intermediate

Answer

A validation error indicates the request itself is malformed or violates basic data constraints (a missing required field, an invalid email format) -- typically caught early, before any business logic runs, and mapped to a 400 Bad Request. A business-logic error indicates the request is well-formed but violates a domain rule (attempting to withdraw more money than an account balance, booking an already-fully-reserved time slot) -- often mapped to a 409 Conflict or 422 Unprocessable Entity, since the request syntax was valid but the requested operation can't be completed given the current state of the system.
// Validation error: malformed request
if (!amount || amount <= 0) throw new ValidationError('Amount must be positive');

// Business-logic error: well-formed request, but violates a domain rule
if (amount > account.balance) throw new InsufficientFundsError('Insufficient balance for this withdrawal');
Real-world example A banking API returns a 400 for a withdrawal request missing the amount field entirely (a validation error caught before touching the database), but returns a 409 for a well-formed withdrawal request that exceeds the account's actual current balance (a business-logic error only detectable after checking the account's state).

Common follow-ups: Why does separating these two error categories with different status codes help API consumers write more precise error-handling logic?;At what layer of the application should validation typically happen versus business-logic checks?

RESTful API Design with Express;Databases & ORMs (MongoDB/Mongoose SQL/Sequelize)
All 15 Error Handling questions