Skip to content
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

Should the API define error codes? #395

Open
msporny opened this issue Jun 25, 2024 · 2 comments
Open

Should the API define error codes? #395

msporny opened this issue Jun 25, 2024 · 2 comments
Labels
ready for PR Issue ready to be resolved via a Pull Request

Comments

@msporny
Copy link
Contributor

msporny commented Jun 25, 2024

The API has the capability of returning ProblemDetail errors today but does not define error codes itself (many of the codes come from the VCDM or status list specifications). It was suggested that the API should define and throw some error codes that are specific to the API such as "UNKNOWN_OPTION_PROVIDED" when an unknown option is provided to an API call.

@msporny msporny added the ready for PR Issue ready to be resolved via a Pull Request label Jun 25, 2024
@dlongley
Copy link
Contributor

We might want to limit the number of error codes to higher level categories, similar to what is seen here:

https://developer.mozilla.org/en-US/docs/Web/API/DOMException#error_names

So that we don't have a new error code for every possible, individual error.

@PatStLouis
Copy link
Collaborator

I think we should be mindful of what we can define that would make testing these features convenient (test software will need something to assert a response on when providing a bad input) while also not making the specification too rigid. This aligns with the comment made by @dlongley.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for PR Issue ready to be resolved via a Pull Request
Projects
None yet
Development

No branches or pull requests

3 participants