[
https://issues.apache.org/jira/browse/METRON-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112723#comment-16112723
]
ASF GitHub Bot commented on METRON-379:
---------------------------------------
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/675
In my opinion, I don't think we want this behavior. I think it may be too
severe given how dirty and sparse our data tends to be.
Does this mean that if you have a stellar expression `FOO(bar)` and the
field `bar` doesn't exist, will we get an exception? If so, given that
messages come through with certain fields which are optional (i.e. some
messages have field `foo` and others might not have a field `foo` depending on
the parser), I think this will result in a fair number of errors.
I'd rather leave it up to the Stellar function creator to figure out if the
field is able to be optional or not rather than having a blanket policy of
throwing an exception. Consider the function `TO_UPPER`. I'd rather
`TO_UPPER` tolerate missing fields by passing them through (i.e.
`TO_UPPER(null) == null`) rather than throw an exception.
One approach to this would be changing the `StellarFunction` interface to a
`List<Optional<Object>>` instead of a `List<Object>` and have the variability
made explicit.
> Stellar - No Error When Adding Variables That Do Not Exist
> ----------------------------------------------------------
>
> Key: METRON-379
> URL: https://issues.apache.org/jira/browse/METRON-379
> Project: Metron
> Issue Type: Bug
> Affects Versions: 0.2.1BETA
> Reporter: Nick Allen
> Assignee: Otto Fowler
> Labels: stellar
>
> Running a Stellar expression like "1 + var + does + not + exist" results in a
> value of 1.0. I would expect an exception or error condition.
> {code:title=StellarTest.java|borderStyle=solid}
> @Test(expected = ParseException.class)
> public void testMissingVariables() {
> String query = "1 + cannot + add + missing + variables";
> run(query, new HashMap<>());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
