lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Braun (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-8434) Use shared instance of CollectionTerminatedException
Date Fri, 27 Jul 2018 22:06:00 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message