Allow to configure exception catching for schema execution
See original GitHub issueCurrently, any exception that is raised in a resolver is catched and converted to a GraphQLError
, which is returned in the errors part of the result (see strawberry/schema/execute.py
).
However, this is not always desirable. For example, the error message might contain sensitive information about the server that should not be accessible to a client. Instead, the server should return a 500 HTTP error (which would work more or less automatically if the exception is not catched). So we need a possibility to tell strawberry that it should not catch all exceptions, but only specific ones. This could mean catching only GraphQLError
, or allowing the user to define a set of exceptions that should be catched.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Error handling - Apollo GraphQL Docs
A client sent the hash of a query string to execute via automatic persisted queries, but the server has disabled APQ. OPERATION_RESOLUTION_FAILURE. The...
Read more >JDBC Exception Handling - How To Handle SQL Exceptions
This JDBC Exception Handling tutorial explains ways to handle SQL Exceptions with the help of programming examples.
Read more >Spring Boot GraphQL Tutorial #8 - Exception Handling with ...
Spring boot graphql supports Spring web's @ExceptionHandler annotations. To enable this we first need to set the graphql property: ...
Read more >7 Handling PL/SQL Errors
To handle raised exceptions, you write separate routines called exception handlers. After an exception handler runs, the current block stops executing and the ......
Read more >Handle errors in ASP.NET Core | Microsoft Learn
Startup exception handling ... Only the hosting layer can handle exceptions that take place during app startup. The host can be configured to ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@N-Maas I think there are 2 issues that you have outlined here and they are slightly different:
1. Error messages might contain sensitive information about the server
This is true and we’d like to make it easier to hide error messages using extensions (see https://github.com/strawberry-graphql/strawberry/issues/1155). Until then here is a custom extension that only allows certain errors to be included in the response:
(I’ll make a PR for this soon so that you can use it directly from strawberry)
2. The server should return a 500 if there are any/some errors
The GraphQL spec actually defines how a server should deal with errors and it explicitly says that errors should be caught and added to the “errors” response: https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability There is also a draft spec for “GraphQL over HTTP” which defines the status codes that the server should return: https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#status-codes
So it’s unlikely that Strawberry will support returning 500 errors if there is an error or selectively catching specific exceptions since it contravenes the spec.
I hope thats helpful and that I characterised your question correctly. Let me know if I’ve missed anything.
@jkimbo indeed. In the case at hand it comes via:
I’ve come up with the following to raise any original errors, which works good for tests, but could also make sense in general then: