[
https://issues.apache.org/jira/browse/LUCENE-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980141#comment-15980141
]
Uwe Schindler commented on LUCENE-7800:
---------------------------------------
What's the reason to remove it in Attributefactory? The MethodHandles called
there are known to not throw unexpected Exceptions!
The problem is that MethodHandles declare throws Throwable, because the
Exceptions are unknown to compiler. The code knows, so it should preserve the
original ones.
-1 to remove it without a reason.
> Remove code that potentially rethrows checked exceptions from methods that
> don't declare them ("sneaky throw" hack)
> -------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7800
> URL: https://issues.apache.org/jira/browse/LUCENE-7800
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Dawid Weiss
> Priority: Minor
> Fix For: 6.x, master (7.0)
>
> Attachments: LUCENE-7800.patch
>
>
> For a long time I considered the "sneaky" throw hack to be a nice way of
> coding around some of Java's limitations (especially with invoking methods
> via reflection or method handles), but with time I started to see how it can
> be potentially dangerous and is nearly always confusing. If you have a Java
> method and its signature doesn't indicate the possibility of a checked
> exception you, as a programmer, simply don't expect it to happen. Never. So,
> for example, you could write:
> {code}
> try {
> luceneApi();
> } catch (RuntimeException | Error e) {
> // Handle unchecked exceptions here.
> }
> {code}
> and consider the code above to be absolutely bullet-proof in terms of
> handling exceptions. Unfortunately with sneaky throws anywhere in the
> "luceneApi" this is no longer the case -- you can receive a checked exception
> that will simply fall through and hit some code frame above.
> So I suggest we remove sneaky throw from the core entirely. It only exists in
> two places -- private methods inside Snowball programs invoked via method
> handles (these don't even declare checked exceptions so I assume they can't
> occur) and AttributeFactory -- here there is a real possibility somebody
> could declare an attribute class's constructor that does throw an unchecked
> exception. In that case I think it is more reasonable to wrap it in a
> RuntimeException than rethrow it as original.
> Alternatively, we can modify the signature of {{createAttributeInstance}} and
> {{getStaticImplementation}} to declare some kind of checked exception (either
> a wrapper or even a Throwable), but I see little reason for it and it'd
> change the API.
--
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
