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

[JEP-14a] Clarified error type precedence. #157

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

springcomp
Copy link
Contributor

@springcomp springcomp commented Mar 15, 2023

See jmespath.test/#28.

This PR brings the following changes:

    _Each function signature declares the types of its input parameters. If any type constraints are not met,
    implementations must indicate that an `invalid-type` error occurred. **If a function parameter accepts values
    constrained to a specific subset of a type and those constraints are not met, implementations must report
-   that an `invalid-value` error occurred.**_
+   that an `invalid-value` error occurred. How and when those errors are raised is implementation specific.**_

+   _The [initial version of this JEP](./jep-014-string-functions.md) had a provision stating that_ “How and when those
+   errors are raised is implementation specific”. _This provision has been removed. Implementation must perform
+   type-checking for all function parameters_ before _attempting to evaluate the set of valid values for a given type._


_Each function signature declares the types of its input parameters. If any type constraints are not met, implementations must indicate that an `invalid-type` error occurred. **If a function parameter accepts values constrained to a specific subset of a type and those constraints are not met, implementations must report that an `invalid-value` error occurred.**_

_The [initial version of this JEP](./jep-014-string-functions.md) had a provision stating that_ “How and when those errors are raised is implementation specific”. _This provision has been removed. Implementation must perform type-checking for all function parameters_ before _attempting to evaluate the set of valid values for a given type._
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The requirement of type validation before range validation should not be limited to string functions... I think this deserves its own JEP rather than a replacement of JEP-14 (in which case I don't think it will be necessary to touch JEP-14 at all, because "How and when those errors are raised is implementation specific" can be interpreted within the context of that constraint (e.g., "how" might be "by exception" vs. "in a separate return value" and "when" might be "when parsing" [where possible] vs. "when evaluating").

@sebastien-rosset
Copy link
Contributor

I opened two related PRs:
jmespath/jmespath.site#115
jmespath/jmespath.site#116

I know understand I opened them in the wrong project. It seems principles for error handling should be covered in their own section rather than within the context of functions. Should I open these PRs under https://github.com/jmespath-community/jmespath.spec? Or should I start a separate discussion or JEP?

@springcomp
Copy link
Contributor Author

I opened two related PRs: [...]. Should I open these PRs under https://github.com/jmespath-community/jmespath.spec? Or should I start a separate discussion or JEP?

Yes please open them in the spec repository here, and, by the way, thank you for your feedback.

I think we can start having discussions around existing features as issues, whereas brainstorming new ideas is better served by discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants