throws x扩展了异常方法签名 [英] throws x extends Exception method signature

问题描述

阅读 可选 ，我碰到一个奇怪的方法签名;我从未见过我的生活：

Reading the JavaDoc of Optional, I bumped in a weird method signature; I never saw in my life:

public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier)
                                throws X extends Throwable

一瞥，我想知道如何通用异常< X扩展Throwable> 是可能的，因为你不能这样做（ here 和这里）。第二个想法，这开始是有道理的，因为这里只是绑定供应商 ...但供应商本身在泛型之前就知道应该是什么类型。

At first glance, I wondered how the generic exception <X extends Throwable> is even possible, since you can't do that (here, and here). On second thought, this starts to make sense, as it is here just to bind the Supplier... but the supplier itself knows exactly what type it should be, before generics.

但是第二行打了我：

• 抛出X 是一个完整的通用异常类型。

• throws X is a complete generic exception type.

然后：

• X扩展Throwable ，世界上这个是什么意思？
  
  
  
  
  • X 已经绑定在方法签名中。
  
  
  
  
  • 这是否以任何方式解决通用异常限制？
  
  
  • 为什么不只是 throws Throwable ，其余的将被擦除类型删除？
  
  
  • X extends Throwable, what in the world does this mean?
    • X is already bound in the method signature.

    一个，不是直接相关的问题：

    And one, not directly related question:

    
    
    • 这个方法是否需要被捕获为 catch（Throwable t） / code>，或由提供的供应商的类型;因为它不能在运行时被检查
    

    • Will this method be required to be caught as catch(Throwable t), or by the provided Supplier's type; since it can't be checked for at runtime?

    推荐答案

    这是我在 Java 8的源代码：

    public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier) throws X
    

    
    
    

    

    • code> X 的上限为 Throwable 。这将在以后重要。
    
    
    • 我们返回一个类型 T ，它绑定到可选的 T
    
    
    • 我们预期一个供应商 X的通配符上限
    
    
    • 我们抛出 X （这是有效的，因为 X 的上限为 Throwable ）。这在 JLS 8.4.6 中指定;只要 X 被视为 Throwable 的子类型，则其声明在此处是有效和合法的。
    
    
    • X has an upper bound of Throwable. This will be important later on.
    • We return a type T which is bound to Optional's T
    • We expect a Supplier which has a wildcard upper bound of X
    • We throw X (which is valid, since X has an upper bound of Throwable). This is specified in JLS 8.4.6; so long as X is seen as a subtype of Throwable, its declaration is valid and legal here.

    有一个开放的错误<关于Javadoc是有误导性的。在这种情况下，最好信任源代码而不是文档，直到错误被声明为固定。

    There is an open bug about the Javadoc being misleading. In this case, it's best to trust the source code as opposed to the documentation until the bug is declared fixed.

    至于为什么我们使用抛出X 而不是 throws Throwable ： X 保证被绑定到 Throwable 在最上边界。如果你想要一个更具体的 Throwable （运行时，检查或错误），那么只需抛出

    As for why we're using throws X instead of throws Throwable: X is guaranteed to be bound to Throwable in the uppermost bounds. If you want a more specific Throwable (runtime, checked, or Error), then merely throwing Throwable wouldn't give you that flexibility.

    对于您最后一个问题：

    这个方法是否需要被捕获（Throwable t）子句？

    Will this method be required to be caught in a catch(Throwable t) clause?

    <链接中的某些东西必须处理异常，这是一个 try ... catch 块或JVM本身。理想情况下，我们希望创建一个供应商绑定到最能传达他们需求的异常。您不必（并且可能应该 不 ）为此案例创建一个 catch（Throwable t）如果您的供应商被绑定到您需要处理的特定异常，那么最好将其用作 catch 后来在链中。

    Something down the chain has to handle the exception, be that a try...catch block or the JVM itself. Ideally, one would want to create a Supplier bound to an exception that best conveyed their needs. You don't have to (and probably should not) create a catch(Throwable t) for this case; if your Supplier is type bound to a specific exception that you need to handle, then it's best to use that as your catch later up in the chain.

    这篇关于throws x扩展了异常方法签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！