Java: checked vs unchecked exception

问题

我已经在StackOverFlow上阅读了有关已检查和未经检查的异常的多个帖子。老实说,我还是不太确定如何正确使用它们。

Joshua Bloch在“Effective Java”中说过

对可恢复条件使用已检查的异常,对编程错误使用运行时异常(第2版中的第58项)

让我们看看我是否正确理解了这一点。

以下是我对已检查异常的理解:

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1.以上是否考虑过检查异常?

2. RuntimeException是未经检查的异常吗?

以下是我对未经检查的异常的理解:

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4.现在,上述代码也不能成为检查异常吗?我可以尝试恢复这样的情况吗?我可以吗?(注意:我的第3个问题在上面的catch里面)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5.为什么人们会这样做?

public void someMethod throws Exception{

}

他们为什么要让异常冒泡?马上处理异常不是更好吗?为什么要将它抛出?
编辑:我应该冒泡确切的异常或使用异常掩盖它吗?

以下是我的读物

In Java, when should I create a checked exception, and when should it be a runtime exception?When to choose checked and unchecked exceptions


#1 热门回答(381 赞)

许多人说不应该使用经过 Checked Exception (即你应该明确地捕获或重新抛出的那些)。例如,它们在C#中被淘汰,大多数语言都没有它们。所以你总是可以抛出RuntimeException的子类(UnChecked Exception)

但是,我认为 Checked Exception 很有用,当你希望强制API的用户思考如何处理异常情况(如果它是可恢复的)时,会使用它们。只是被检查的异常在Java平台中被过度使用,这让人们讨厌它们。

Here's my extended view on the topic

至于具体问题:

  • NumberFormatException是否考虑检查异常?

    No。NumberFormatExceptionRuntimeException的子类。为什么?我不知道。 (但应该有一个方法 isValidInteger(..))

  • RuntimeException是未经检查的异常吗?

    对,就是这样。

  • 我该怎么办?

    这取决于此代码的位置以及你希望发生的内容。如果它在UI层中 - 捕获它并显示警告;如果它在服务层 - 根本不抓住它 - 让它冒泡。只是不要吞下这个 Exception。如果在大多数情况下发生异常,你应该选择以下其中一种:记录它并返回重新抛出它(声明它由方法抛出)通过在构造函数中传递当前的异常来构造一个新的异常。

  • 现在,上面的代码难道也不是一个 Checked Exception 吗?我可以尝试恢复这样的情况吗?

    它可能是。但是没有什么可以阻止你捕获 Checked Exception

  • 为什么人们在 throws 子句中添加 Exception?

    大多数情况下,因为人们懒得考虑要捕捉什么和重新抛出什么。抛出异常是一种不好的做法,应该避免。

唉,没有任何一条规则可以让你确定何时捕获,何时重新抛出,何时使用 Checked Exception 以及何时使用 UnChecked Exception 。我同意这会导致很多混乱和很多错误的代码。 Bloch说明了一般原则(你引用了它的一部分)。一般原则是在可以处理的地方重新抛出异常。


#2 热门回答(204 赞)

某些东西是否是“已检查的异常”与你是否捕获它或在catch块中执行的操作无关。它是异常类的属性。除了RuntimeException及其子类之外,任何作为Exception的子类的东西都是一个经过检查的异常。

Java编译器强制你捕获已检查的异常或在方法签名中声明它们。它本来应该提高程序安全性,但大多数意见似乎是它不值得它创造的设计问题。

Why do they let the exception bubble up? Isn't handling the error sooner better? Why bubble up?

因为这是 Exception 的全部要点。没有这种可能性,你就不需要 Exception。它们使你能够在你选择的级别处理错误,而不是强迫你在最初发生的低级方法中处理它们。


#3 热门回答(60 赞)

  • 以上是否考虑了检查异常?否如果处理异常,则不会使其成为Checked Exception,如果它是RuntimeException。
  • RuntimeException是未经检查的异常吗?是

Checked Exceptions是java.lang.Exception的子类Unchecked Exceptions是java.lang.RuntimeException的子类

抛出已检查异常的调用需要包含在try {}块中,或者在方法调用者的上一级中处理。在这种情况下,当前方法必须声明它抛出所述异常,以便调用者可以做出适当的安排来处理异常。

希望这可以帮助。

问:我应该冒泡确切的异常还是使用异常掩盖它?

答:是的,这是一个非常好的问题和重要的设计考虑因素。 Exception类是一个非常通用的异常类,可用于包装内部低级异常。你最好创建一个自定义异常并将其包装在其中。但是,还有一个重大问题 - 永远不要掩盖潜在的原始根本原因。对于前者,永远不要 做:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

而是做以下:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

吃掉原始根本原因导致实际原因无法恢复,这对于生产支持团队来说是一场噩梦,他们可以访问的是应用程序日志和错误消息。虽然后者是一个更好的设计,但很多人不经常使用它,因为开发人员只是无法将基础消息传递给调用者。所以要做一个坚定的说明:“总是传递实际的异常”,无论是否包含在任何特定于应用程序的异常中。

尝试捕捉RuntimeExceptions

作为一般规则的RuntimeExceptions不应该是try-catched。它们通常表示编程错误,应该保持不变。相反,程序员应该在调用可能导致RuntimeException的某些代码之前检查错误情况。例如:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

这是一个糟糕的编程习惯。相反,应该像以下一样进行空检查 -

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

但有时候这种错误检查很昂贵,例如数字格式化,请考虑这个 -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

这里预调用错误检查不值得付出努力,因为它本质上意味着复制parseInt()方法中的所有字符串到整数转换代码 - 并且如果由开发人员实现则容易出错。所以最好不要试试try-catch。

因此NullPointerException和NumberFormatException都是RuntimeExceptions,捕获NullPointerException应该替换为正常的空检查,而我建议显式捕获NumberFormatException以避免可能引入容易出错的代码。