8000 Allow user definition of functions that avoid parameter error checking · Issue #523 · google/cel-go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Allow user definition of functions that avoid parameter error checking #523

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.

Sign up for GitHub

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

Jump to bottom
Closed
2 of 3 tasks
kortschak opened this issue Mar 28, 2022 · 0 comments · Fixed by #525
Closed
2 of 3 tasks

Allow user definition of functions that avoid parameter error checking #523

kortschak opened this issue Mar 28, 2022 · 0 comments · Fixed by #525

Comments

@kortschak
Copy link
Contributor
kortschak commented Mar 28, 2022 •
edited
Loading

Feature request checklist

  • There are no issues that match the desired change
  • The change is large enough it can't be addressed with a simple Pull Request
  • If this is a bug, please file a Bug Report.

Change

Allowing users to specify that this class of function in a limited way (only as global functions) would allow users to construct a form of error evasion/try evaluation on potentially failable expressions. This is important for expressions that have multiple parts where some can fail but an incompletely successful evaluation is still useful.

See https://groups.google.com/g/cel-go-discuss/c/YmQcarGB5V0/m/oS7qa1ppBgAJ for additional context.

Example

This would allow a user to define (bike-shed spelling) a "try" evaluation that lowers the significance of an error to a string message:

{
    "always_successful": safe_expression(par0),
    "sometimes_successful_1": try(less_safe_expression(par1)),
    "sometimes_successful_2": try(less_safe_expression(par2), "error message"),
}

which in the case that the evaluations of less_safe_expression failed might give a final result like:

{
    "always_successful": "yay!",
    "sometimes_successful_1": "par1 value evaluation failure result",
    "sometimes_successful_2": {"error message": "par2 value evaluation failure result"},
}

or on success

{
    "always_successful": "yay!",
    "sometimes_successful_1": "hurrah!",
    "sometimes_successful_2": "hurrah!",
}

Alternatives considered

I considered the option of adding a language operator that allows a similar outcome, but it becomes a language feature that is likely to be abused and would be less flexible.

I'm happy to do the work to implement this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add logic to allow functions to accept errors args kortschak/cel-go
1 participant
@kortschak
0