jmespath-community / jmespath.spec

JMESPath Specification
6 stars 3 forks source link

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

Open springcomp opened 1 year ago

springcomp commented 1 year ago

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._
sebastien-rosset commented 1 year ago

I opened two related PRs: https://github.com/jmespath/jmespath.site/pull/115 https://github.com/jmespath/jmespath.site/pull/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 commented 1 year ago

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.