How do interceptors and exception filters divide error-handling responsibility in NestJS?
Interceptors via catchError() remap exception types — they convert domain or ORM errors into HttpException subclasses before the filter sees them. Exception filters shape the HTTP error response sent to the client. Interceptors fix what the exception is; filters fix how the error response looks. Interceptors run before filters in the pipeline.
- 1
Interceptors (catchError) — translate exception types: EntityNotFoundError to NotFoundException.
- 2
Exception filters — format the HTTP response: shape the JSON body, set headers, log errors.
- 3
Interceptors run before filters in the pipeline — remap exception type first, then format the response.
- 4
Use interceptors when the error type needs changing; use filters when only the response format needs changing.
- 5
Always re-throw from interceptor catchError if the error is not handled — let the filter catch it.
Scenario Questions
0-2 years experience
- 1You have a NestJS controller that throws a NotFoundException. If you add a global exception filter but also have a logging interceptor, which one will see the error first and why?
- 2How would you use an interceptor to transform a successful response while still letting an exception filter handle errors for the same route?
- 3If you forget to bind an exception filter to a route, what happens when an error is thrown inside an interceptor?
2-5 years experience
- 1We noticed validation errors are being logged twice, once in our interceptor and again in the exception filter. Walk me through why that is happening and how you'd fix it.
- 2During a recent deployment, a custom HttpException wasn't being caught by our global exception filter when it originated from a middleware. Explain the chain of responsibility and what changes you'd make.
- 3Our team wants to add a retry interceptor for external API calls but still have a central exception filter for all uncaught errors. How would you structure them to avoid conflicts?
5-8 years experience
- 1At scale, we have many microservices each with their own interceptors and a shared exception filter library. Discuss the trade‑offs of handling errors in interceptors vs. filters, especially regarding performance and consistency.
- 2We need to implement a feature where certain errors should bypass the global exception filter and be returned as raw responses. How would you design the interceptor/filter interaction to support this without breaking existing error handling?
- 3Explain how you would test that interceptors and exception filters correctly partition error handling across a complex request pipeline.
8+ years experience
- 1Our organization is migrating legacy Express middleware into NestJS modules. The legacy code relies on throwing errors that are caught by a top‑level error handler. How would you redesign the error‑handling strategy using interceptors and exception filters to maintain backward compatibility while adopting NestJS best practices?
- 2Across multiple teams, some put business‑logic error handling in interceptors, others in exception filters. Propose a governance model and architectural guidelines to standardize responsibility division.
- 3If we plan to expose a GraphQL API alongside REST, how would you align interceptor and exception filter usage to provide a unified error format without duplicating logic?
Follow-up Questions
- Can you give an example of when you'd handle an error in an interceptor instead of a filter?
- How does the order of global versus scoped interceptors affect error propagation?
- What considerations does this division introduce for unit testing?