Add support for @catch on fragments/queries/mutations and aliased inline fragments #4838
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@catch
was originally conceived as a means for handling field errors, so we built it as a directive on fields. However, as the design evolved we opted to make it additionally catch any errors nested within it. With this newer approach, there’s no reason to limit@catch
to just fields. Any GraphQL construct which gets read as a concrete value should be able to operate as a@catch
boundary.This PR adds support for marking fields/queries/mutations and aliased fragments as
@catch
boundaries. This means:Result
type@semanticNonNull
values nested within the fragment/operation/mutation/aliased fragment will be typed using their semantic type (non-nullable)One particularly nice thing this enables is that it allows
@catch
to act as a non-destructive alternative to@throwOnFieldError
.Additional Bug Fixes
Along the way I noticed and fixed a few bugs:
@catch
or@throwOnFieldError
@catch(to: NULL)
directive would not actually cause the value to become null.