[jira] [Commented] (SCXML-180) Prevent NPEs for possible null value returned from Evaluator.eval* methods

["Woonsan Ko (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SCXML-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837938#comment-13837938 ] 

Woonsan Ko commented on SCXML-180:
----------------------------------

According to the spec [1], "if a conditional expression cannot be evaluated as a boolean value ('true' or 'false') or if its evaluation causes an error, the SCXML Processor MUST treat the expression as if it evaluated to 'false' and MUST place the error 'error.execution' in the internal event queue."
So, the current #evalCond() implementation should be improved to return false when the evaluation result is null or non Boolean object or any exception occurs at least.

By the way, I couldn't find any source location caring about 'error..' events when error occurs to comply with the specification (3.12.2 Errors). That can be a good improvement and there seems to be no jira issue for that yet. I'll create a separate issue for that improvement.

[1] http://www.w3.org/TR/scxml/#ConditionalExpressions

> Prevent NPEs for possible null value returned from Evaluator.eval* methods
> --------------------------------------------------------------------------
>
>                 Key: SCXML-180
>                 URL: https://issues.apache.org/jira/browse/SCXML-180
>             Project: Commons SCXML
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Ate Douma
>            Assignee: Woonsan Ko
>             Fix For: 2.0
>
>
> I just encountered the following NPE:
>   java.lang.NullPointerException
>     at org.apache.commons.scxml2.semantics.SCXMLSemanticsImpl.filterTransitionsSet(SCXMLSemanticsImpl.java:415)
>     at org.apache.commons.scxml2.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:124)
>     at org.apache.commons.scxml2.SCXMLExecutor.reset(SCXMLExecutor.java:256)
>     at org.apache.commons.scxml2.SCXMLExecutor.go(SCXMLExecutor.java:349)
> This turned out to be caused by an transition condition (evaluated through Jexl) resulting in, and thus also returning, a null value.
> A quick scan through the usages of Evaluator.eval* method shows several locations within SCXML where it always assumes an non-null value (Boolean or otherwise) to be returned. All possible sources for unexpected NPEs.
> I think that for at least the Evaluator#evalCond method, which is assumed to return a Boolean, either an error should be catched/returned or maybe even assume null == Boolean.FALSE.
>  



--
This message was sent by Atlassian JIRA
(v6.1#6144)