[英]Java: Catching an Exception whose super-type is in the throws list
I've occasionally written Java code in the following manner: 我偶尔会以以下方式编写Java代码:
public static TrustManager[] getTrustManagers(TruststoreParams tsParams)
throws IOException, GeneralSecurityException {
TrustManagerFactory tmf = null;
FileInputStream fis = null;
try {
...
return tmf.getTrustManagers();
}
catch (NoSuchAlgorithmException nsae) {
throw new RuntimeException(nsae);
}
finally {
...
}
where I am treating the NoSuchAlgorithmException
a bit differently than other security-related exceptions. 在这里,我对待
NoSuchAlgorithmException
的方式与其他与安全性有关的异常有所不同。 I am wondering if there is anything fundamentally wrong with the exception handling approach above where I have the GeneralSecurityException
super-type in the throws list, but I am specifically catching and handling one of its sub-types and wrapping it as a RuntimeException
. 我想知道上面的异常处理方法是否存在根本错误,在异常处理方法中,我在throws列表中具有
GeneralSecurityException
超级类型,但是我专门捕获并处理其子类型之一,并将其包装为RuntimeException
。
How would you rewrite the above method skeleton, if differently than how I have it setup above, and why? 如果与我上面设置的方法不同,您将如何重写上述方法框架,为什么?
It looks reasonable to me. 在我看来,这很合理。 By throwing a RuntimeException, you're essentially treating that case as a fatal error, which would make sense if your application requires you to use a particular algorithm.
通过抛出RuntimeException,您实际上将这种情况视为致命错误,如果您的应用程序要求您使用特定算法,这将是有意义的。
Catching a more-specific exception than you throw can make sense, in that it's always good to respond to specific cases IF YOU HAVE A SPECIFIC RESPONSE. 捕获比抛出更具体的异常是有意义的,因为如果您有特定的响应,则对特定情况做出响应总是好的。 In this case, though, why wrap it in a
RuntimeException
? 但是,在这种情况下,为什么将其包装在
RuntimeException
呢? Is it a worse case than GeneralSecurityException
, ie it's so bad you want to bypass the usual handling by the caller? 是否比
GeneralSecurityException
更糟糕的情况呢?也就是说,它太糟糕了,您想绕过调用者的常规处理? A different GeneralSecurityException
wouldn't be as bad? 一个不同的
GeneralSecurityException
会不会那么糟糕?
My approach has changed over the years. 这些年来,我的方法已经改变。 Lately I declare a lot fewer exceptions, typically just ones that the caller CAN programmatically deal with, mostly business-related (eg
NoSuchUser
). 最近,我声明了很少的异常,通常只是调用者可以通过编程处理的异常,大多数与业务相关(例如
NoSuchUser
)。 "System" or infrastructure issues get put into a RuntimeException
of some variety, since the caller really can't do anything but bail out on. “系统”或基础结构问题被放入各种
RuntimeException
中,因为调用者实际上除了救助外别无选择。
In your case, is there anything the caller could do with the IOException
or the GeneralSecurityException
? 在您的情况下,调用者可以使用
IOException
或GeneralSecurityException
做任何事情吗? If not, I wouldn't put them in the signature at all (it only confuses things for the caller) and just wrap any exceptions that occur in a RuntimeException
. 如果不是这样,我根本不会将它们放在签名中(它只会使调用者感到困惑),而只包装
RuntimeException
中发生的所有异常。
I think that if one of the methods above is interested in NoSuchAlgorithmException
then it should deal with it without further assistance. 我认为,如果以上方法之一对
NoSuchAlgorithmException
感兴趣,那么它应该在没有进一步帮助的情况下进行处理。
I would do something like 我会做类似的事情
try {
...
trustManager.getTrustmanagers(...);
} catch (GeneralSecurityException e) {
if (e instanceof NoSuchAlgorithmException) {
// do something special
} else {
// do regular error handling
}
}
In this case no superfluous structures need to be created which trigger actions over a distance, which I find always confusing when I stumble over them. 在这种情况下,不需要创建多余的结构来触发远距离的动作,当我偶然发现它们时,我总是感到困惑。
I must admit that I prefer RuntimeExceptions over checked exception genrally, but not in this case, since it just adds special cases on top of special cases. 我必须承认,一般来说我更喜欢RuntimeExceptions而不是Checked异常,但在这种情况下则不然,因为它只是在特殊情况之上添加了特殊情况。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.