调用堆栈: catch与throws

Question

什么时候使用"catch“，什么时候使用"throws"？

try {
    //stuff
} 
catch (MyException me) {
    //stuff
}

对比

public void doSomething() throws MyException {
    //stuff
}

在“抛出”的情况下，把我的catch放在调用堆栈的什么地方？

Main
    ----- Function 1
        ----- Function 2
            ----- Function 3 (generate exception)

如果我将异常从函数3传播到函数2，为什么函数2不应该这样做呢？因此，最终我将管理"main“中的所有异常，并且我认为将所有代码放在一个go0d块中不是一种尝试实践，不是吗？

那么在"catch“和"throws”之间做出选择的逻辑方式是什么呢？在第二种情况下，我应该将catch放在调用堆栈中的什么位置？

Answer 1

它们基本上是彼此相反的。throws表示允许函数抛出异常；catch表示块( try)块预期可能抛出异常，并准备好处理它。

举个球的比喻，投手throws是捕手所期望的异常。接球手把球接住( catches )，然后以某种方式控制住它。(嗯，也许这个比喻有点离谱，因为接球手通常通过将球扔回投手来处理球。:) )这里投手是一个方法，捕手是一个try-catch-[finally]块。

Answer 2

您应该声明，每当方法的调用者需要捕获或传递它时，该方法都会抛出一个检查过的异常。无论何时，只要您准备好处理异常，就应该当场捕获该异常。

例如，如果您正在编写一个具有图形界面的程序，并且该程序也具有从文件读取的核心，则核心类不具备告诉用户存在错误的能力，这是图形界面的工作。因此，核心程序中的方法(如getSomethingFromFile() )可能会抛出IOException。如果图形界面调用getSomethingFromFile()并确定存在读取错误，则图形界面可以向用户显示一个对话框，因此它已准备好捕捉异常。在这种情况下，getSomethingFromFile()调用应该包含在try/catch中。

Answer 3

如果您打算使用throw - catch方法来处理错误，那么实际的错误处理必须由负责执行此操作的组件来完成，特别是因为这允许您将逻辑封装在它所属的位置。

异常是由某个知道如何处理它以及必须采取的操作过程的类捕获的。在某些特殊情况下，您可以通过将异常包装在另一个异常中来重新抛出它(将异常设置为其原因)。以任何对象模型为例，任何低级异常都被包装在一个PersistenceException中，该异常的起因可能是SQLSyntaxException。

如果您没有适当的工具来管理特定上下文中的异常，而您希望将其传播到可以正确管理的更高层/层，则throws就会发挥作用。

让我举一个“大图”的例子：

1. Save entity to database
2. Communication error
3. Exception is ，因此您的持久性对象必须对其进行处理。
4. it，
5. it，包装它并将其重新抛出为您自己的异常之一(我反对让持久性异常传播到更高层...
6. persistence 抛出一个异常，该异常被模型捕获。
7. 模型重试operation.
8. Another失败(相同的代码包装+ throw).
9. The模型通知失败，<>e137>将报告<>e238提升到视图中。这就是我所说的被“知道”该怎么做的人抓到的意思。
10. 视图会向用户显示"No saving “。

该示例同时包含throw和catch案例，我希望它有助于澄清。