[
https://issues.apache.org/jira/browse/LUCENE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473890
]
Hoss Man commented on LUCENE-793:
---------------------------------
Hmmm... well my paranoia says that if we are trying to make the Exceptions more
explicit, then any place we currently "throw Foo" we should "throw Bar" where
"Foo.class.isAssignable(Bar.class)" ... but if we currently mix/match
IOException/IllegalStateException in cases of corruption then I guess it makes
sense to use CorruptIndexException extends IOException.
(the only alternative i can think of would be a CorruptIndexIOException and a
CorruptIndexStateException .. but you're probably right .. i don't very many
people are worried about catching the IllegalStateException and doing anyhitng
special that they aren't already doing when they catch the IOException.
> Javadocs should explain possible causes for IOExceptions
> --------------------------------------------------------
>
> Key: LUCENE-793
> URL: https://issues.apache.org/jira/browse/LUCENE-793
> Project: Lucene - Java
> Issue Type: Bug
> Components: Javadocs
> Reporter: Michael McCandless
> Assigned To: Michael McCandless
> Priority: Minor
> Attachments: LUCENE-793.patch
>
>
> Most methods in Lucene reserve the right to throw an IOException. This can
> occur for nearly all methods from low level problems like wrong permissions,
> transient IO errors, bad hard drive or corrupted file system, corrupted
> index, etc, but for some methods there are also more interesting causes that
> we should try to document.
> Spinoff of this thread:
> http://www.gossamer-threads.com/lists/lucene/java-user/44929
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
