[
https://issues.apache.org/jira/browse/CALCITE-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17189672#comment-17189672
]
Julian Hyde commented on CALCITE-4219:
--------------------------------------
Your mistake is trying to use a verification framework. Reality is too complex
to model. The assumptions made in the code are valid, in the vast majority of
cases, because the code is written by people who understand the actual
constraints.
> Clarify SqlCall#getOperandList() nullability
> --------------------------------------------
>
> Key: CALCITE-4219
> URL: https://issues.apache.org/jira/browse/CALCITE-4219
> Project: Calcite
> Issue Type: Sub-task
> Components: core
> Affects Versions: 1.25.0
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> {{getOperandList()}} is implemented by a number of different {{SqlCall}}
> sub-classes, and the list often includes null values.
> The implementation is typically {{return ImmutableNullableList.of(...}}
> However, {{getOperandList()}} is used a lot, and the code assumes that the
> resulting values are non-null. The same happens for {{SqlCall#operand(int)}}.
> The workaround is to declare {{getOperandList()}} and {{operand(int)}} to
> return non-nullable values (even though nulls are possible), and we could add
> suppressions at the side which returns {{ImmutableNullableList}}.
> The solution might be behind the lines of adding
> {{nonNullableOperand(int)}}-like methods that would return non-nullable
> values and throw meaningful errors in case the value turns out to be null.
> Another option might be to ensure all the fields are non-nullable (e.g.
> create dummy SqlNode for empty values).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
