You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2013/12/03 14:31:00 UTC
[jira] [Updated] (SCXML-180) Prevent NPEs for possible null value
returned from Evaluator.eval* methods
[ https://issues.apache.org/jira/browse/SCXML-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated SCXML-180:
----------------------------
Description:
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.
was:
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 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.
> 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
> 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)