[
https://issues.apache.org/jira/browse/LUCENE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980320#comment-15980320
]
Dawid Weiss commented on LUCENE-7796:
-------------------------------------
bq. That's not true. It is misuse, but behavior is still expected. The same
happens if you change a method to suddenly throw a checked Exception.
I don't think this is a good example, Uwe. What you're talking about is JVM
validation (which indeed treats all exceptions equal). What I'm talking about
is Java specification. From java specification viewpoint it is a compilation
error if your depending class changes and suddently throws an unchecked
exception. The fact that you can substitute a new class with different method
signatures and re-run binaries is a weakness in java "linking" system and is,
to me, unrelated.
What I'm talking about can be showcased fairly easily. Consider this code:
{code}
public class TestCustomAttr extends LuceneTestCase {
public static interface CustomAttr extends Attribute {
}
public static final class CustomAttrImpl extends AttributeImpl {
public CustomAttrImpl() throws Exception {
throw new Exception("bah");
}
@Override
public void clear() {}
@Override
public void reflectWith(AttributeReflector reflector) {}
@Override
public void copyTo(AttributeImpl target) {}
}
private class CustomFilter extends TokenFilter {
protected CustomFilter(TokenStream input) {
super(input);
addAttribute(CustomAttr.class);
}
@Override
public boolean incrementToken() throws IOException {
return false;
}
}
public void testUncheckedExceptionInAttrImpl() {
Analyzer a = new Analyzer() {
@Override
protected TokenStreamComponents createComponents(String fieldName) {
Tokenizer source = new WhitespaceTokenizer();
TokenStream filters = source;
filters = new CustomFilter(source);
return new TokenStreamComponents(source, filters);
}
};
a.tokenStream("", "foo");
}
}
{code}
As a Java programmer I have every reason to believe {{a.tokenStream}} never
throws a checked exception, yet it surely does. I fail to see how this is
verified by Java MethodHandles lookup (in fact, as the example above shows, it
isn't).
I'm really fine in leaving it as is -- I understand how it works internally.
But I do have a strong feeling sneaky throws aren't the "right" way in terms of
how the Java language was designed (not talking about the JVM here). If you
need a motivational example -- this is exactly the same situation as with
method handles ({{invokeExact}}, etc.) or the old reflection API ({{Method}})
-- they declare Throwable, ExecutionException or other exception type wrapper
as a java-language-compatible way of propagating unknown (checked or unchecked)
exception from the (unknown) callee. Straight and simple, no surprises.
> Make reThrow idiom declare RuntimeException return type so callers may use it
> in a way that compiler knows subsequent code is unreachable
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7796
> URL: https://issues.apache.org/jira/browse/LUCENE-7796
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Trivial
> Fix For: 6.x, master (7.0)
>
>
> A spinoff from LUCENE-7792: reThrow can be declared to return an unchecked
> exception so that callers can choose to use {{throw reThrow(...)}} as an
> idiom to let the compiler know any subsequent code will be unreachable.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
