>>bq. Shouldnt it throw a runtime exception (unsupported operation?) or something? >>What is the difference between adding an abstract method and adding a method that throws exception in regards to jar drop in back compat? >>In both cases when you drop your new jar in you get an exception, except in the latter case exception is deferred.
Yeah, its dicey - I suppose the idea is that, if you used the code as you used to, it wouldnt try and call getPayloadSpans? And so if you kept using non payloadspans functionality, you would be set, and if you tried to use payloadspans you would get an exception saying the class needed to be updated? But if you make it abstract, we lose jar drop (I know I've read we don't have it for this release anyway) in and everyone has to implement the method. At least with the exception, if you are using the class as you used to, you can continue to do so with no work? Not that I 've considered it for very long at the moment. I know, I see your point - this back compat stuff is always dicey - thats why I throw it out there with a question mark - hopefully others will continue to chime in. On Thu, Jul 16, 2009 at 9:38 AM, Earwin Burrfoot (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731939#action_12731939] > > Earwin Burrfoot commented on LUCENE-1748: > ----------------------------------------- > > bq. Shouldnt it throw a runtime exception (unsupported operation?) or > something? > What is the difference between adding an abstract method and adding a > method that throws exception in regards to jar drop in back compat? > In both cases when you drop your new jar in you get an exception, except in > the latter case exception is deferred. > > > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be > abstract > > > ------------------------------------------------------------------------------ > > > > Key: LUCENE-1748 > > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > > Project: Lucene - Java > > Issue Type: Bug > > Components: Query/Scoring > > Affects Versions: 2.4, 2.4.1 > > Environment: all > > Reporter: Hugh Cayless > > Fix For: 2.4.2 > > > > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, > far away from the actual source of the problem. > > It would be much better for this kind of thing to show up at compile > time, I think. > > Thanks! > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- -- - Mark http://www.lucidimagination.com
