Advice on handling service-level errors in GraphQL

[chrome grotto]

Hi there, I'm pretty new to NestJS and I'm being asked by client devs to handle expected errors more gracefully app-wide (e.g. when a resource isn't found, return, say, null or an empty array instead of surfacing the error to the client). Given the specifics of the app, we'd like to avoid handling errors in the service-level and instead handle expected errors in or around the resolver.

Would this be a good use case for interceptors? I'm mostly wondering if interceptors will run before the GraphQL side of things is run. If I were to handle an error inside an interceptor and return a null or an empty array, would it still be validated by GraphQL (e.g. the @Query() decorator)?

[fallen stream]

I think interceptors with graphql isn't going to work great, since enhancers are not executed at field level (https://docs.nestjs.com/graphql/other-features#execute-enhancers-at-the-field-resolver-level).

So if you had @Query(Book[]) books query, and @ResolveField() author on the Book ObjectType, if the author resolver failed, your interceptor wouldn't be able to handle that (unless you enable enhancers at field level, as mentioned in the link).

Unfortunately, I don't have any best practice to give you at the moment. At the moment, I'm doing the same freestyle you're trying to escape 😁

[chrome grotto]

Thanks for the response. Out of curiosity what does your "freestyle" approach look like right now?

[fallen stream]

Here's one resolver. I'm not proud of it, but it's doing it's job (and it was done quick).
Random exceptions where I left them, sometimes the underlying prisma exceptions can propagate through, basically nothing a client-side implementation could hook onto in a systematic way.

[deft idol]

This helped me a lot: https://www.youtube.com/watch?v=RDNTP66oY2o

I created entities for each "query failure"