You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2008/04/17 06:17:21 UTC
[jira] Commented: (LUCENE-1264) Use of IOException in analysis
component method signatures leads to poor error management
[ https://issues.apache.org/jira/browse/LUCENE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589826#action_12589826 ]
Hoss Man commented on LUCENE-1264:
----------------------------------
while i don't disagree that it would be nice to have some more domain specific checked exceptions in future iterations of the Lucene API, i would like to point out that this comment is irrelevant...
{quote}
IOException, as one of the older and dustier Java exceptions, lacks a constructor over a 'cause' exception.
So, if a Tokenizer (for example) uses some complex underlying facility that throws arbitrary exceptions, the coder has two bad choices: wrap an IOException around some string derived from the real problem, or throw an unchecked wrapper.
{quote}
IOException does not have a constructor that takes a "cause" arg, but like all Exceptions it does support initCause(Throwable cause) as part of the Throwable contract.
{code}
try {
throw new RuntimeException("foo");
} catch (Exception e) {
throw (IOException)(new IOException("problem")).initCause(e);
}
{code}
> Use of IOException in analysis component method signatures leads to poor error management
> -----------------------------------------------------------------------------------------
>
> Key: LUCENE-1264
> URL: https://issues.apache.org/jira/browse/LUCENE-1264
> Project: Lucene - Java
> Issue Type: Bug
> Components: Analysis
> Affects Versions: 2.3.1
> Reporter: Benson Margulies
>
> Methods such as 'next' and 'reset' are defined to throw only IOException.
> IOException, as one of the older and dustier Java exceptions, lacks a constructor over a 'cause' exception.
> So, if a Tokenizer (for example) uses some complex underlying facility that throws arbitrary exceptions, the coder has two bad choices: wrap an IOException around some string derived from the real problem, or throw an unchecked wrapper.
> Please consider adding a new checked exception to the signature of these methods that implements the 'cause' pattern.
--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org