lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1264) Use of IOException in analysis component method signatures leads to poor error management
Date Thu, 17 Apr 2008 04:17:21 GMT

    [ 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


Mime
View raw message