Feature request checklist
Change
If an function in the CEL interpreter panics, the expression evaluation terminates and
an error is provided to the caller. This behavior could be relaxed to be more graceful,
by specifically wrapping extension functions (possibly just async functions) in
panic-recover blocks to better handle unexpected errors.
Example
bad_call() || true <-- currently errors if there's a panic in bad_call; however, this
expression could evaluate to completion with panic-recover blocks.
Alternatives considered
Do nothing - panics should probably not be gracefully tolerated, but there may be
exceptions to this rule, and perhaps, instead this should be a wrapper offered to
users to do a panic / recover block around specific functions where they are most
worried about a panic -- such as from a third party library.
Feature request checklist
Change
If an function in the CEL interpreter panics, the expression evaluation terminates and
an error is provided to the caller. This behavior could be relaxed to be more graceful,
by specifically wrapping extension functions (possibly just async functions) in
panic-recover blocks to better handle unexpected errors.
Example
bad_call() || true<-- currently errors if there's a panic inbad_call; however, thisexpression could evaluate to completion with panic-recover blocks.
Alternatives considered
Do nothing - panics should probably not be gracefully tolerated, but there may be
exceptions to this rule, and perhaps, instead this should be a wrapper offered to
users to do a panic / recover block around specific functions where they are most
worried about a panic -- such as from a third party library.