You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Adrien Grand (JIRA)" <ji...@apache.org> on 2012/09/26 15:47:07 UTC
[jira] [Created] (LUCENE-4438) Lucene40StoredFieldsReader's
constructor calls close() instead of IOUtils.closeWhileHandlingException in
its finally block
Adrien Grand created LUCENE-4438:
------------------------------------
Summary: Lucene40StoredFieldsReader's constructor calls close() instead of IOUtils.closeWhileHandlingException in its finally block
Key: LUCENE-4438
URL: https://issues.apache.org/jira/browse/LUCENE-4438
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
It would be nice to have automated tests for this kind of things (similarly to the check-forbidden-api task).
Here is the discussion I just had with Uwe on IRC:
{noformat}
15:32 < jpountz> ThetaPh1: I just saw that Lucene40StoredFieldsReader's constructor calls close in its finally block. I think it is wrong since close might throw an IOE (should be catched), am I
correct? If yes, then is it something we could test with ASM (similarly to the forbidden API checks)?
15:32 <@ThetaPh1> it does not use IOUtils?
15:33 <@ThetaPh1> we cannot check this with asm easily
15:33 <@ThetaPh1> we could only forbid calling Closeable.close() and exclude IOUtils from that
15:34 <@ThetaPh1> so the correct fix is to use IOUtils when clsoing
15:34 <@ThetaPh1> it also checks for null and suppresses exceptions
15:36 < jpountz> ThetaPh1: no, it does no
15:36 <@ThetaPh1> its a bug :-)
15:36 <@ThetaPh1> but not serious
15:36 <@ThetaPh1> for local files it never throws exceptions
15:36 < jpountz> ok
15:37 < jpountz> I think catching calls to Closeable.close would already be nice
15:37 <@ThetaPh1> but we might think about disallowing Closeable.close()
15:37 < jpountz> I'll open an issue
15:37 <@ThetaPh1> we can add that as a separate check-forbidden-apis file
15:37 <@ThetaPh1> but exclude IOUtils from the fileset
15:37 <@ThetaPh1> unfortunately all tests do this
15:38 <@ThetaPh1> so i would restriuct this to non-tests, too
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4438) Lucene40StoredFieldsReader's
constructor calls close() instead of IOUtils.closeWhileHandlingException in
its finally block
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463814#comment-13463814 ]
Uwe Schindler commented on LUCENE-4438:
---------------------------------------
{noformat}
[15:44] ThetaPh1: jpountz: problem
[15:44] ThetaPh1: super.close() in a subclass
[15:44] ThetaPh1: this should be allowed
[15:46] ThetaPh1: so the forbidden-apis checker cannot handle that without a special case
{noformat}
> Lucene40StoredFieldsReader's constructor calls close() instead of IOUtils.closeWhileHandlingException in its finally block
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-4438
> URL: https://issues.apache.org/jira/browse/LUCENE-4438
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Adrien Grand
> Priority: Minor
> Fix For: 4.1, 5.0
>
>
> It would be nice to have automated tests for this kind of things (similarly to the check-forbidden-api task).
> Here is the discussion I just had with Uwe on IRC:
> {noformat}
> 15:32 < jpountz> ThetaPh1: I just saw that Lucene40StoredFieldsReader's constructor calls close in its finally block. I think it is wrong since close might throw an IOE (should be catched), am I
> correct? If yes, then is it something we could test with ASM (similarly to the forbidden API checks)?
> 15:32 <@ThetaPh1> it does not use IOUtils?
> 15:33 <@ThetaPh1> we cannot check this with asm easily
> 15:33 <@ThetaPh1> we could only forbid calling Closeable.close() and exclude IOUtils from that
> 15:34 <@ThetaPh1> so the correct fix is to use IOUtils when clsoing
> 15:34 <@ThetaPh1> it also checks for null and suppresses exceptions
> 15:36 < jpountz> ThetaPh1: no, it does no
> 15:36 <@ThetaPh1> its a bug :-)
> 15:36 <@ThetaPh1> but not serious
> 15:36 <@ThetaPh1> for local files it never throws exceptions
> 15:36 < jpountz> ok
> 15:37 < jpountz> I think catching calls to Closeable.close would already be nice
> 15:37 <@ThetaPh1> but we might think about disallowing Closeable.close()
> 15:37 < jpountz> I'll open an issue
> 15:37 <@ThetaPh1> we can add that as a separate check-forbidden-apis file
> 15:37 <@ThetaPh1> but exclude IOUtils from the fileset
> 15:37 <@ThetaPh1> unfortunately all tests do this
> 15:38 <@ThetaPh1> so i would restriuct this to non-tests, too
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (LUCENE-4438) Lucene40StoredFieldsReader's
constructor calls close() instead of IOUtils.closeWhileHandlingException in
its finally block
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463817#comment-13463817 ]
Robert Muir commented on LUCENE-4438:
-------------------------------------
We could at least investigate the list?
Also, unlike when writing (MockIndexOutputWrapper.java), we never throw random
exceptions from MockIndexInputWrapper.java when random exceptions are enabled.
So any such bugs currently wont be found.
> Lucene40StoredFieldsReader's constructor calls close() instead of IOUtils.closeWhileHandlingException in its finally block
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-4438
> URL: https://issues.apache.org/jira/browse/LUCENE-4438
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Adrien Grand
> Priority: Minor
> Fix For: 4.1, 5.0
>
>
> It would be nice to have automated tests for this kind of things (similarly to the check-forbidden-api task).
> Here is the discussion I just had with Uwe on IRC:
> {noformat}
> 15:32 < jpountz> ThetaPh1: I just saw that Lucene40StoredFieldsReader's constructor calls close in its finally block. I think it is wrong since close might throw an IOE (should be catched), am I
> correct? If yes, then is it something we could test with ASM (similarly to the forbidden API checks)?
> 15:32 <@ThetaPh1> it does not use IOUtils?
> 15:33 <@ThetaPh1> we cannot check this with asm easily
> 15:33 <@ThetaPh1> we could only forbid calling Closeable.close() and exclude IOUtils from that
> 15:34 <@ThetaPh1> so the correct fix is to use IOUtils when clsoing
> 15:34 <@ThetaPh1> it also checks for null and suppresses exceptions
> 15:36 < jpountz> ThetaPh1: no, it does no
> 15:36 <@ThetaPh1> its a bug :-)
> 15:36 <@ThetaPh1> but not serious
> 15:36 <@ThetaPh1> for local files it never throws exceptions
> 15:36 < jpountz> ok
> 15:37 < jpountz> I think catching calls to Closeable.close would already be nice
> 15:37 <@ThetaPh1> but we might think about disallowing Closeable.close()
> 15:37 < jpountz> I'll open an issue
> 15:37 <@ThetaPh1> we can add that as a separate check-forbidden-apis file
> 15:37 <@ThetaPh1> but exclude IOUtils from the fileset
> 15:37 <@ThetaPh1> unfortunately all tests do this
> 15:38 <@ThetaPh1> so i would restriuct this to non-tests, too
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org