有效的try / catch块用法？

应该使用catch块来编写逻辑，即处理流控制等吗？还是仅仅为了抛出异常？它会影响代码的效率或可维护性吗？

在catch块中写逻辑有什么副作用（如果有）？

编辑：

我见过一个Java SDK类，其中他们在catch块内编写了逻辑。例如（摘录自java.lang.Integer课堂）：

        try {
            result = Integer.valueOf(nm.substring(index), radix);
            result = negative ? new Integer(-result.intValue()) : result;
        } catch (NumberFormatException e) {
            String constant = negative ? new String("-" + nm.substring(index))
                                       : nm.substring(index);
            result = Integer.valueOf(constant, radix);
        }

编辑2：

我正在阅读一个教程，他们将其视为在异常内编写例外情况逻辑的优势：

异常使您能够编写代码的主要流程，并处理其他地方的特殊情况。

有什么具体准则，何时在catch块中编写逻辑，何时不编写逻辑？

您引用的示例是由于API设计不佳（没有一种干净的方法可以检查String是否为有效整数，除非尝试对其进行解析并捕获异常）。

在技​​术层面上，throw和try / catch是控制流构造，使您可以跳上调用堆栈，仅此而已。向上调用堆栈隐式地连接源中未紧密结合的代码，这不利于可维护性。因此，仅在需要这样做时才使用它，而替代方法甚至更糟。在被广泛接受的情况下选择更糟是错误处理（特殊返回代码是需要检查和手工传递到调用堆栈的每一层）。

如果您遇到其他选择更糟的情况（并且您确实仔细考虑了所有选择），那么我想说使用throw and try / catch进行控制流程就可以了。教条不是判断的好替代品。

这往往取决于语言和范式。

我的大部分工作都是用Java（有时是C ++）完成的。趋势是仅将例外用于特殊情况。关于Stack Overflow，有一些关于Java异常的性能开销的问题，正如您所看到的，这并不是可以忽略的。还有其他一些问题，例如代码的可读性和可维护性。如果使用得当，异常可以将错误处理委派给适当的组件。

但是，在Python中，要求宽恕比允许权限容易的想法成为主流。在Python社区中，这称为EAFP，它与C风格语言中的“跨越式外观”（LBYL）方法形成对比。

这不是考虑try / catch块的最佳方法。考虑try / catch块的方法是这样的：发生了故障，哪里是处理此特定故障的最佳位置。那可能是代码的下一行，可能是调用链的二十个级别。无论在哪里，它都应该在哪里。

catch块的作用取决于错误以及您可以采取的措施。有时可以简单地将其忽略（无法删除其中没有大量数据的暂存文件），有时将其用于将函数返回值设置为true或false（java的int parse方法），有时您将退出程序。所有这些都取决于错误。

要理解的重要部分是：catch block ==我知道如何处理。

捕获块仅应用于处理异常，而不能用于控制流。在任何情况下，如果您想使用异常来管理流程，最好检查一下先决条件。

处理带有异常的流很慢并且在语义上是不正确的。

应该使用catch块来编写逻辑，即处理流控制等吗？还是仅仅为了抛出异常？它会影响代码的效率或可维护性吗？

首先，忘记“例外应在特殊情况下使用”的概念。也不要担心效率，直到您的代码执行得令人无法接受并且已经确定要知道问题出在哪里。

在没有条件的情况下以简单的顺序执行操作时，代码最容易理解。异常通过从常规流中删除错误检查来提高可维护性。执行是遵循99.9％的时间还是50％的时间还是20％的时间正常流都没有关系。

当函数无法返回值，过程无法完成预期的操作或构造函数无法生成可用对象时，引发异常。这使程序员可以假设函数总是返回可用的结果，过程总是完成请求的操作，构造的对象总是处于可用状态。

我在异常处理代码中看到的最大问题是，程序员应该在不应该编写try / catch块的情况下编写它们。例如，在大多数Web应用程序中，如果数据库请求引发异常，则控制器中无法执行任何操作。最高级别的一个通用catch子句就足够了。然后，控制器代码可以很高兴地忽略磁盘崩溃或数据库脱机等问题的可能性。

捕获块不应用于编写代码逻辑。它们仅应用于处理错误。一个示例是（1）清理所有分配的资源，（2）打印有用的消息，（3）正常退出。

确实可以滥用异常并导致不良goto后果。但这并不会使它们无用。如果使用得当，它们可以改善代码的许多方面。