What is an exception filter in NestJS and when does it run?
An exception filter catches unhandled exceptions thrown anywhere in the request pipeline — middleware, guards, interceptors, pipes, or the handler itself — and converts them into an HTTP response. The @Catch() decorator specifies which exception type(s) to intercept. Omitting it catches everything.
- 1
@Catch(HttpException) — only handles HttpException and its subclasses.
- 2
@Catch() with no argument — catches every exception including non-HTTP errors.
- 3
@Catch(NotFoundException, BadRequestException) — handles multiple types.
- 4
host.switchToHttp() provides access to req and res objects.
- 5
exception.getResponse() returns either a string or an object depending on how the exception was thrown.
Scenario Questions
0-2 years experience
- 1You need to return a 404 when a resource isn’t found. How would you use an exception filter in NestJS to handle this, and when does the filter get invoked?
- 2If you add a custom exception filter globally, what happens when a controller throws a built‑in HttpException? Walk me through the flow.
2-5 years experience
- 1We have a microservice that sometimes throws a database timeout error. The current global filter logs the error but masks the original status code. How would you adjust the filter to preserve the original response, and why might the filter not have run as expected?
- 2During a recent deployment, some endpoints started returning generic 500 responses even though you threw custom exceptions. What could cause the exception filter to be bypassed, and how would you debug it?
5-8 years experience
- 1Our API gateway aggregates responses from several NestJS services. We want a single exception filter at the gateway to translate service‑specific errors into a unified error format. What design considerations and edge cases would you address, and when does the filter execute in the request lifecycle?
- 2Explain the performance implications of applying exception filters at the controller level versus globally in a high‑throughput NestJS app. How would you decide where to place them, and what trade‑offs exist?
8+ years experience
- 1We are migrating a legacy Express app to NestJS and need to preserve existing error‑handling middleware semantics. How would you design a strategy to replace Express error handlers with NestJS exception filters across multiple teams, ensuring consistent behavior during the transition?
- 2Consider a multi‑tenant SaaS platform where each tenant can define custom error‑mapping rules. How would you architect exception filtering to support per‑tenant customization without sacrificing maintainability, and when in the request pipeline would those filters run?
Follow-up Questions
- Can you describe the order NestJS uses when multiple exception filters are applied?
- What’s the difference between a filter registered with @Catch() on a class and one added via app.useGlobalFilters?
- How does an exception filter interact with NestJS’s built‑in HttpException handling?