[ES|QL] Make EvaluatorMapper.fold() throw VerificationException for folding time errors Option#1 #116861
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: #112672
Resolves: #99758
Resolves: #108519
This PR is working in progress, and the goal is to wrap the exceptions caught at constant folding(planning time errors) into
VerificationException
, in stead of returning null + warning. And this is a breaking change.It differentiates user errors from data errors, if the literal values provided in the query text is wrong, the errors should be caught at planning time as
VerificationException
, if the data coming from indices are wrong, null + warnings could be returned at execution time.Previously, the warnings/exceptions created by
ExpressionEvaluator
are stored in thread_context, and they are not returned to planner after constant folding -EvaluatorMapper.fold()
, so they are not visible to planner. This PR redirects the warnings/exceptions caught byExpressionEvaluator
during constant folding toDriverContext
, and planner can retrieve the warnings/exceptions fromDriverContext
, and wrap them intoVerificationException
.I'd like to request an early review of this approach to see if it is in the right direction.
Conversion functions
andcase
haven't been covered by this PR yet, they will be covered in this PR.InvalidArgumentException
,IllegalArgumentException
etc. when validating the literal values coded in the query, they are not wrapped intoVerificationException
by this PR yet. It is doable however it is another kind of breaking change, the client needs to capture a different type of exception, we can decide whether to do it or not, and if we decide to do it, whether to do it in the same or a separate PR.