-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return errors from railway programming model #274
Comments
What's the type of |
@johnberzy-bazinga what do you think about switching to |
@xperiandri I think that makes sense. Let's see if the spec has anything to say about this. It might be that invalid inputs are fatal errors so execution should halt. But at the very least we should handle the exception and set the error path to the root of the query. If change to the |
@johnberzy-bazinga what do you think about such signature of coerce functions? abstract CoerceInput : Value -> Result<struct(obj * string seq), string seq>
abstract CoerceValue : obj -> Result<struct(obj * string seq), string seq> or abstract CoerceInput : Value -> Result<struct(obj * obj seq), obj seq>
abstract CoerceValue : obj -> Result<struct(obj * obj seq), obj seq> As some warnings can also be produced for successfully validated inputs as it is done in https://github.com/fsprojects/Chessie |
Implemented in #418 |
Description
We use Chessie and resolver function returns a result. Then I want to unwrap that result and return value or errors as GraphQL response like this:
However as long as type is not nullable, returning null produces error.
Repro steps
Result
type of Chassie libraryExpected behavior
Ability to handle
Result
type and pass errors without raising an exception.Actual behavior
nullResolverError is called and
GraphQLException
is returnedKnown workarounds
Raise exception after resolver execution
Related information
The text was updated successfully, but these errors were encountered: