[
https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560400#comment-16560400
]
Hoss Man commented on LUCENE-8434:
----------------------------------
bq. ... It could have been represented as part of a return value that clients
would need to deal with as opposed to a RuntimeException they'd need to catch.
IIRC: there have been multiple dicussions over the years about the possibility
of {{collect(...)}} having a return value, but since the common case is to keep
collecting, the need for IndexSearcher to explicitly check the return value on
every call to {{collect}} was prohibitive in terms of performance (compared to
just catching CollectionTerminatedException).
> Use shared instance of CollectionTerminatedException
> ----------------------------------------------------
>
> Key: LUCENE-8434
> URL: https://issues.apache.org/jira/browse/LUCENE-8434
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael Braun
> Priority: Minor
>
> Creating exceptions and filling in the stack is expensive (see SOLR-11242 and
> SOLR-11314 for two such examples). CollectionTerminatedException is used as a
> signaling mechanism - there are zero instances in code that actually log that
> it occurred or make use of anything other than the fact that it occurred
> (unlike Solr's EarlyTerminatingCollectorException, for instance). Exceptions
> really should be for something exceptional - the use of
> CollectionTerminatedException is in place of polluting return values with
> this condition and is just used as a signal to callers.
> Because CollectionTerminatedException is never inspected directly and is
> effectively a different return condition, it doesn't make as much sense to
> generate new Exceptions with fresh stack traces every time - either change
> the signatures or share the object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
