[
https://issues.apache.org/jira/browse/LUCENE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980332#comment-15980332
]
Uwe Schindler edited comment on LUCENE-7796 at 4/23/17 9:06 AM:
----------------------------------------------------------------
Did you know that the Class.newInstance() also throws checked Exceptions
without declaring them! So the old code before using MethodHandles was wrong,
too! (Java 9 deprecated Class#newInstance() in favor of using Constructor which
wrapps). If you search for Class#newInstance in LuSolr's source code you see
many more.
[http://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#newInstance--]
As said before I'd check the ctor on the initial reflection that it does not
throw checked Exceptions. The problem is that MethodHandles.findConstructor()
and the returned MethodHandle's MethodType don't show the Exceptions. But with
reflective jl.reflect.Constructor instances this can be checked.
In general, with MethodHandle's you are leaving the type system anyways, so it
is always possible that types don't match at runtime. So I don't see this as a
problem. If you want to catch all Exceptions in some source code, catch
Throwable and handle based on type + rethrow. That is what all programs out
there do.
was (Author: thetaphi):
Did you know that the Class.newInstance() also throws checked Exceptions
without declaring them! So the old code before using MethodHandles was wrong,
too! (Java 9 deprecated Class#newInstance() in favor of using Constructor which
wrapps). If you search for Class#newInstance in LuSolr's source code you see
many more.
As said before I'd check the ctor on the initial reflection that it does not
throw checked Exceptions. The problem is that MethodHandles.findConstructor()
and the returned MethodHandle's MethodType don't show the Exceptions. But with
reflective jl.reflect.Constructor instances this can be checked.
In general, with MethodHandle's you are leaving the type system anyways, so it
is always possible that types don't match at runtime. So I don't see this as a
problem. If you want to catch all Exceptions in some source code, catch
Throwable and handle based on type + rethrow. That is what all programs out
there do.
> 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
