-
Notifications
You must be signed in to change notification settings - Fork 0
Error handling #1
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
base: schema-coordinates
Are you sure you want to change the base?
Error handling #1
Conversation
- Add error handling as proposed by Benjie
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the schema coordinate resolution logic and introduces explicit error handling as proposed by Benjie.
- Split the previous monolithic resolver into multiple specialized functions.
- Introduce explicit error throwing for missing schema elements in certain coordinate types.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
File | Description |
---|---|
src/utilities/resolveSchemaCoordinate.ts | Refactored coordinate resolution into multiple functions with explicit error handling for missing directives, types, and members. |
src/utilities/tests/resolveSchemaCoordinate-test.ts | Updated tests to expect thrown errors for specific error scenarios. |
Comments suppressed due to low confidence (2)
src/utilities/resolveSchemaCoordinate.ts:115
- Consider making the error handling behavior consistent; for instance, throwing an error when a directive is missing (as done in directive argument resolution) might provide clearer feedback than returning undefined.
if (!directive) { return; }
src/utilities/resolveSchemaCoordinate.ts:235
- The error message for non-object/interface types in member coordinate resolution may be ambiguous; consider specifying that the coordinate is only applicable to Object or Interface types to help diagnose the issue more clearly.
throw new Error(`Expected ${inspect(typeName)} to be defined as a type in the schema.`);
// Let {enumValueName} be the value of the second {Name}. | ||
const enumValue = type.getValue(memberName); | ||
|
||
// TODO: Add a spec line about returning undefined if the member name does not exist. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add documentation and tests to clearly define the expected behavior when a member name does not exist, ensuring that the resolver's behavior is well-specified for these edge cases.
Copilot uses AI. Check for mistakes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the errors are a little misleading, I've posted suggestions
Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com>
df01558
to
cc9df08
Compare
This PR refactors the schema coordinate resolution logic and introduces explicit error handling as proposed by @benjie.
resolveASTSchemaCoordinate
function into multiple specializedresolveTypeCoordinate
,resolveMemberCoordinate
, etc... functions.