[
https://issues.apache.org/jira/browse/UIMA-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16556163#comment-16556163
]
Marshall Schor commented on UIMA-5845:
--------------------------------------
This is a bug. The select framework has a call "nullOK" whereby you can set
(or reset) how you want get() (and most forms of single(...) )in its various
forms to react when it would return null.
The nullOK setting (defaults to false) when true, allows returning null instead
of throwing an exception, for the various forms of get(...) and the various
forms of single(...) except for the no-argument form of single, which always
has nulls being ok to return.
The defaults are of course, adjustable. If you think other defaults for get
and single... are better (remember, there is also a singleOrNull set of APIs as
well) please discuss.
I'm not sure it's worth the trouble to introduce another category of exception
class, but don't feel strongly. I guess I don't see the user making much ( if
any ) special use of this subcategory.
> Inconsistent behavior on going beyond index limits in SelectFS
> --------------------------------------------------------------
>
> Key: UIMA-5845
> URL: https://issues.apache.org/jira/browse/UIMA-5845
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 3.0.0SDK
> Reporter: Richard Eckart de Castilho
> Priority: Major
>
> The behavior of trying to address annotations outside the index appears to be
> inconsistent.
> For example, the following call returns `null`:
> {code}
> String text = "one two three";
> tokenBuilder.buildTokens(jCas, text);
> List<Token> tokens = new ArrayList<Token>(select(jCas, Token.class));
>
> for (Token token : tokens) {
> new AnalyzedText(jCas, token.getBegin(), token.getEnd()).addToIndexes();
> }
>
> Token firstToken = tokens.get(0);
> AnalyzedText x = jCas.select(AnalyzedText.class).preceding(firstToken,
> 0).get();
> {code}
> However, this code trying go from the end of the index to before the first
> item throws a CASRuntime exception:
> {code}
> String text = "Rot wood cheeses dew?";
> tokenBuilder.buildTokens(jCas, text);
> assertThatExceptionOfType(CASRuntimeException.class)
> .isThrownBy(() -> jCas.select(Token.class).backwards().get(4))
> .withMessage("CAS does not contain any '" + Token.class.getName() +
> "' instances shifted by: 4.");
> {code}
> It would seem reasonably to either always return null or to always thrown an
> exception. If an exception is thrown, it would seem reasonable to introduce a
> subtype of the CASRuntimeException, e.g. a CASIndexOutOfBounds exception or
> something the likes. CASRuntimeException seems very general.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
