Description
When calling a GraphQLScalarType's parseLiteral or parseValue methods, those methods can either return undefined or throw an error -- in either case, the value is considered invalid and an error is included in the response. However, returning undefined results in a generic error message about the type being invalid, while throwing a TypeError allows us to provide additional details as to why the provided value was invalid.
For all built-in scalars, parseValue throws a TypeError when the value is invalid, while parseLiteral always returns undefined. This results in inconsistent messaging when validating literal inputs compared to variables. For example:
Expected type Int, found 2147483648.
compared with
Variable "$first" got invalid value 2147483648; Expected type Int; Int cannot represent non 32-bit signed integer value: 2147483648
Anywhere parseLiteral is actually called, it's already wrapped with a try/catch and any error is handled appropriately -- namely here and here.
I know this is fairly trivial, but is there any reason to avoid throwing a TypeError inside parseLiteral when the value is invalid? Even if parseLiteral and parseValue can't share the exact same logic, it might make sense to reconcile them, at least in that regard. Would you accept a PR to that affect?