[
https://issues.apache.org/jira/browse/LUCENE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16560393#comment-16560393
]
Michael Braun commented on LUCENE-8434:
---------------------------------------
Thanks [~thetaphi] - did not know about the OmitStackTraceInFastThrow
optimization! When I have some free time I'll look to see if this is kicking in
for all practical cases.
In general though, as to using a RuntimeException as an alternative to
adjusting signatures - where has the balance been found between representing an
alternate scenario with an Exception versus a representative return value
containing that it happened? 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
