[
https://issues.apache.org/jira/browse/UIMA-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558270#comment-16558270
]
Marshall Schor commented on UIMA-5845:
--------------------------------------
Arguments:
* Pro exceptions as the default:
** imagine the use cases, and if a majority of them are such that users would
not write code to handle null cases , it might be best to throw exceptions by
default.
*** This follows a general design philosophy for UIMA, which is to allow users
to be successful, without being themselves super-duper software engineers
(users are more likely NLP people, or some other domain experts). To achieve
this, UIMA has checks ( and sometimes protection ) for things (e.g. accidental
index corruption).
** The form of the override for this is 8 characters, {{nullOK()}} and easy to
understand
*** If the default was the other way, we would need a {{nullNotOK()}} or
{{nullOK(false)}} or {{exceptionWhenNull()}} or ??? all of which seem more
cumbersome.
** Having users who are prepared to handle null returns being required to
write \{{nullOK()}}serves to document that null might be returned.
* Pro nulls being OK as the default:
** Users don't have to write {{nullOK()}} - less distracting code, if this was
the accepted normal behavior wanted "most of the time".
Thinking about the use cases, my feeling is that people using {{get(..)}} and
{{single(..)}} most of the time don't expect nulls and won't be providing code
to handle these cases, so the exception route seems better, on balance, to me..
> 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)
