proposal to add 'error' function #27
Conversation
There was a problem hiding this comment.
Thanks for the proposal. My initial high level feedback is I'd like to see more motivation why this needs to be part of JMESPath. Historically we've stayed away from the schema validation space and you mentioned JSON schema as an alternative. While how heavyweight JSON schema is depends on the specific implementation/library, I'm hesitant for JMESPath to become an alternative (there's a lot more functionality needed to provide the type of validation people might expect).
Additional things that would help in this section:
- Concrete use cases
- Other tools that have similar functionality
As always though, I'd love to hear from others what they think.
proposals/0013-error-function.md
Outdated
|
|
||
| ## Motivation | ||
|
|
||
| AFAIK, there is no dedicated function to raise a runtime error within a JMESpath expression. |
There was a problem hiding this comment.
The motivation section should go into more detail as to why JMESPath expressions need the ability to raise a runtime error. The existing errors are intended for cases where the user has made a mistake in their expression. JMESPath is primarily a language for filtering/extracting/reshaping JSON data, and not really about schema validation. This section should make a convincing case for that.
There was a problem hiding this comment.
I have added a section with concrete use cases and improved the motivation section.
There was a problem hiding this comment.
@jamesls , does this address your concerns?
This PR creates a JEP to address #22.
The proposal is to add a new error function that takes a string expression. If the error function is evaluated, an error is raised with the specified message.