How do interceptors handle errors vs exception filters in NestJS — what is the division of responsibility?

If you need to log the execution time of a controller method and also want to return a custom error response when something throws, which would you use – an interceptor, an exception filter, or both? Explain how you'd set them up.

Suppose a service throws a standard JavaScript Error inside a request pipeline. What will happen if you only have a global exception filter but no interceptor that catches errors? Describe the flow.

You added an interceptor that transforms the response data, but after a recent change, some errors are being swallowed and the client receives a 200 with an empty body. Walk me through why that might happen and how you'd fix it using exception filters.

During debugging, you notice that a thrown HttpException is being logged twice – once in an interceptor and again in an exception filter. How would you adjust the responsibilities to avoid duplicate handling?

In a microservices gateway, you need to enforce request validation, log latency, and ensure consistent error formatting across dozens of services. How would you architect the use of interceptors and exception filters to balance performance and maintainability?

Consider a scenario where an interceptor performs async operations and may reject a promise. How does NestJS propagate that error compared to an exception filter, and what are the implications for high‑throughput endpoints?

Your organization is migrating legacy NestJS modules that currently use custom error‑handling middleware to a unified strategy. How would you decide which error handling logic belongs in interceptors versus exception filters, and what guidelines would you set for future teams?

When scaling to thousands of concurrent requests, you notice that global exception filters add noticeable latency. Propose a design that minimizes overhead while preserving clear separation of concerns between interceptors and exception filters.