Right now libgraphql APIs emit errors of varying detail, with varying structure and error messages, and likely makes all future additions/changes/improvements to errors over time a breaking change.
This is because I’ve taken the shortcut of quickly building ad-hoc error variants as i build out the library — which means we’re thorough on expressing many different error cases; But the terminology used by error variants, display messages for them, and included details (eg some include lots of location info, some not enough) for each error variant is generally inconsistent.
Additionally, all error variants are exhaustive — which means adding new errors over time is technically a breaking change to any consumers that match on the previously-exhaustive set of errors.
Right now libgraphql APIs emit errors of varying detail, with varying structure and error messages, and likely makes all future additions/changes/improvements to errors over time a breaking change.
This is because I’ve taken the shortcut of quickly building ad-hoc error variants as i build out the library — which means we’re thorough on expressing many different error cases; But the terminology used by error variants, display messages for them, and included details (eg some include lots of location info, some not enough) for each error variant is generally inconsistent.
Additionally, all error variants are exhaustive — which means adding new errors over time is technically a breaking change to any consumers that match on the previously-exhaustive set of errors.