[ https://issues.apache.org/jira/browse/LUCENE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154442#comment-13154442 ]
Uwe Schindler commented on LUCENE-3464: --------------------------------------- bq. Thats no problem, it just calls super.doOpenIfChanged, see my proof of concept. This throws UOE as FilterIndexReader (correctly!!!) does not implement doOpenIfChanged. If it would implement if a FilterIndexReader without any doOpenIfChanged impl would be horribly broken as it would return an unfiltered reader!!! > Rename IndexReader.reopen to make it clear that reopen may not happen > --------------------------------------------------------------------- > > Key: LUCENE-3464 > URL: https://issues.apache.org/jira/browse/LUCENE-3464 > Project: Lucene - Java > Issue Type: Bug > Reporter: Michael McCandless > Assignee: Michael McCandless > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3464.3x.patch, LUCENE-3464.patch, > LUCENE-3464.patch, LUCENE-3464_see_its_just_fine.patch > > > Spinoff from LUCENE-3454 where Shai noted this inconsistency. > IR.reopen sounds like an unconditional operation, which has trapped users in > the past into always closing the old reader instead of only closing it if the > returned reader is new. > I think this hidden maybe-ness is trappy and we should rename it > (maybeReopen? reopenIfNeeded?). > In addition, instead of returning "this" when the reopen didn't happen, I > think we should return null to enforce proper usage of the maybe-ness of this > API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org