为了回答最后一个问题(上面的其他问题似乎都得到了彻底的回答)，“我应该冒泡出确切的异常还是使用exception掩盖它?”

我猜你的意思是这样的:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

不，总是声明尽可能精确的异常，或者一个这样的列表。你声明你的方法能够抛出的异常是你的方法和调用者之间契约的一部分。抛出"FileNotFoundException"意味着可能文件名无效，无法找到该文件;调用者需要聪明地处理这个问题。抛出异常意味着“嘿，该死的事情发生了。交易。”这是一个非常糟糕的API。

在第一篇文章的注释中有一些例子，其中“throws Exception”是一个有效且合理的声明，但对于您所编写的大多数“正常”代码来说，情况并非如此。

我只是想添加一些根本不使用受控异常的理由。这不是一个完整的答案，但我觉得它确实回答了你的部分问题，并补充了许多其他的答案。

Whenever checked exceptions are involved, there's a throws CheckedException somewhere in a method signature (CheckedException could be any checked exception). A signature does NOT throw an Exception, throwing Exceptions is an aspect of implementation. Interfaces, method signatures, parent classes, all these things should NOT depend on their implementations. The usage of checked Exceptions here (actually the fact that you have to declare the throws in the method signature) is binding your higher-level interfaces with your implementations of these interfaces.

让我给你们看一个例子。

让我们有一个像这样漂亮干净的界面

public interface IFoo {
    public void foo();
}

现在我们可以编写方法foo()的许多实现，就像这样

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

类Foo完全没问题。现在让我们第一次尝试Bar类

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

这个类Bar不能编译。由于InterruptedException是一个已检查异常，您必须捕获它(在方法foo()中使用try-catch)或声明您正在抛出它(在方法签名中添加抛出InterruptedException)。因为我不想在这里捕获这个异常(我希望它向上传播，这样我就可以在其他地方正确地处理它)，让我们改变签名。

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

这个类Bar也不能编译!Bar的方法foo()不会覆盖IFoo的方法foo()，因为它们的签名不同。我可以删除@Override注释，但我想编程接口IFoo像IFoo foo;然后再决定使用哪个实现，比如foo = new Bar();如果Bar的方法foo()没有覆盖IFoo的方法foo，当我执行foo.foo();它不会调用Bar的foo()实现。

To make Bar's public void foo() throws InterruptedException override IFoo's public void foo() I MUST add throws InterruptedException to IFoo's method signature. This, however, will cause problems with my Foo class, since it's foo() method's signature differs from IFoo's method signature. Furthermore, if I added throws InterruptedException to Foo's method foo() I would get another error stating that Foo's method foo() declares that it throws an InterruptedException yet it never throws an InterruptedException.

正如您所看到的(如果我在解释这些东西方面做得不错的话)，抛出InterruptedException这样的检查异常的事实迫使我将我的接口IFoo绑定到它的一个实现上，这反过来又会对IFoo的其他实现造成严重破坏!

这就是受控异常很糟糕的一个重要原因。在帽。

一种解决方案是捕获已检查异常，将其包装在未检查的异常中，然后抛出未检查的异常。

为什么他们让异常冒出来?早点处理错误不是更好吗?为什么要冒出来?

For example let say you have some client-server application and client had made a request for some resource that couldn't be find out or for something else error some might have occurred at the server side while processing the user request then it is the duty of the server to tell the client why he couldn't get the thing he requested for,so to achieve that at server side, code is written to throw the exception using throw keyword instead of swallowing or handling it.if server handles it/swallow it, then there will be no chance of intimating to the client that what error had occurred.

注意:为了清楚地描述发生的错误类型，我们可以创建自己的Exception对象并将其抛出给客户端。

这里有一个简单的规则可以帮助你做出决定。它与Java中如何使用接口有关。

以你的类为例，想象一下为它设计一个接口，该接口描述类的功能，但不描述底层实现(接口应该这样)。假设您可能以另一种方式实现该类。

查看接口的方法，并考虑它们可能抛出的异常:

如果方法可以抛出异常，而不管底层实现是什么(换句话说，它只描述功能)，那么它可能应该是接口中的受控异常。

如果异常是由底层实现引起的，那么它不应该出现在接口中。因此，它必须是类中的未检查异常(因为未检查异常不需要出现在接口签名中)，或者必须将其包装并作为接口方法的一部分的已检查异常重新抛出。

To decide if you should wrap and rethrow, you should again consider whether it makes sense for a user of the interface to have to handle the exception condition immediately, or the exception is so general that there is nothing you can do about it and it should propagate up the stack. Does the wrapped exception make sense when expressed as functionality of the new interface you are defining or is it just a carrier for a bag of possible error conditions that could also happen to other methods? If the former, it might still be a checked exception, otherwise it should be unchecked.

通常不应该计划“冒泡”异常(捕获并重新抛出)。异常要么应该由调用者处理(在这种情况下它被检查)，要么应该一直向上到高级处理程序(在这种情况下，如果它不被检查是最简单的)。

受控异常在编译时由JVM检查，并与资源相关(文件/db/流/套接字等)。受控异常的动机是，在编译时，如果资源不可用，应用程序应该在catch/finally块中定义一个替代行为来处理这个异常。

未经检查的异常纯粹是编程错误、错误计算、空数据甚至业务逻辑中的失败都可能导致运行时异常。在代码中处理/捕获未检查的异常是绝对没问题的。

解释摘自http://coder2design.com/java-interview-questions/

许多人说检查异常(即你应该显式地捕获或重新抛出的异常)根本不应该使用。例如，它们在c#中被淘汰了，大多数语言都没有它们。因此，您总是可以抛出RuntimeException的子类(未检查的异常)

然而，我认为受控异常是有用的——当你想强迫API的用户思考如何处理异常情况(如果它是可恢复的)时，就使用它们。只是受控异常在Java平台中被过度使用了，这让人们讨厌它们。

以下是我对这个话题的扩展观点。

关于具体问题:

Is the NumberFormatException consider a checked exception? No. NumberFormatException is unchecked (= is subclass of RuntimeException). Why? I don't know. (but there should have been a method isValidInteger(..)) Is RuntimeException an unchecked exception? Yes, exactly. What should I do here? It depends on where this code is and what you want to happen. If it is in the UI layer - catch it and show a warning; if it's in the service layer - don't catch it at all - let it bubble. Just don't swallow the exception. If an exception occurs in most of the cases you should choose one of these: log it and return rethrow it (declare it to be thrown by the method) construct a new exception by passing the current one in constructor Now, couldn't the above code also be a checked exception? I can try to recover the situation like this? Can I? It could've been. But nothing stops you from catching the unchecked exception as well Why do people add class Exception in the throws clause? Most often because people are lazy to consider what to catch and what to rethrow. Throwing Exception is a bad practice and should be avoided.

遗憾的是，没有单一的规则可以让您决定何时捕获、何时重新抛出、何时使用已检查异常和何时使用未检查异常。我同意这会导致很多混乱和很多糟糕的代码。布洛赫阐述了总体原则(你引用了其中的一部分)。一般的原则是将异常重新抛出到可以处理它的层。