支持或反对使用Try / Catch作为逻辑运算符的论点

我刚刚在我们公司的应用程序中发现了一些可爱的代码，这些代码使用Try-Catch块作为逻辑运算符。
意思是，“执行一些代码，如果抛出此错误，则执行此代码，但如果抛出此错误，则执行此第三项操作”。
它使用“最后”作为出现的“其他”语句。
我知道这本质上是错的，但是在我去打架之前，我希望能有一些深思熟虑的论点。
嘿，如果您有关于以这种方式使用Try-Catch的参数，请务必告知。

对于任何想知道的人，该语言是C＃，所讨论的代码大约有30多行，并且正在寻找特定的异常，因此它无法处理所有异常。

异常处理往往是处理流控制的昂贵方法（对于C＃和Java肯定如此）。

构造异常对象时，运行时会做很多工作-将堆栈跟踪在一起，弄清楚异常的处理位置等等。

如果将流控制语句用于流控制，则无需扩展所有这些内存和CPU资源成本。

此外，还有一个语义问题。例外是针对特殊情况，而不是正常的流量控制。应该使用异常处理来处理意外的/异常情况，而不是像正常的程序流程那样处理，因为否则，未捕获的异常将告诉您更少的信息。

除了这两个以外，还有其他人在阅读代码。以这种方式使用异常并不是大多数程序员所期望的，因此会影响可读性和代码的可理解性。当人们看到“异常”时，就会想到-一件不好的事情发生了，不应该正常发生的事情。因此，以这种方式使用异常只会造成混乱。

我刚刚在我们公司的应用程序中发现了一些可爱的代码，这些代码使用Try-Catch块作为逻辑运算符。意思是，“执行一些代码，如果抛出此错误，则执行此代码，但是如果抛出此错误，则执行此第三项操作”。它使用“最后”作为出现的“其他”语句。我知道这本质上是错误的...

你怎么知道？我放弃了所有这些“知识”，现在只是相信最简单的代码是最好的。假设您想将字符串转换为Optional，如果解析失败，该字符串为空。没错：

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

我完全不同意“例外是针对特殊条件”的通常解释。当函数无法返回可用值或方法不能满足其后置条件时，将引发异常。在出现明显的性能问题之前，多长时间抛出一次异常都无关紧要。

异常通过允许将错误处理与正常流程分开来简化了代码。只需编写尽可能简单的代码，如果使用try-catch或引发异常更容易，则可以这样做。

异常通过减少代码的路径数来简化测试。没有分支的函数将完成或引发异常。具有多个if语句以检查错误代码的函数具有许多可能的路径。错误条件之一很容易弄错，或者完全忘记一个条件很容易，因此某些错误条件会被忽略。

当使用异常执行控制流时，调试和维护工作非常困难。

从本质上讲，异常被设计为一种用于更改程序的正常控制流的机制-执行异常活动，引起异常副作用，以此作为摆脱特别紧密的绑定的方法，而这种绑定无法用较简单的方式处理手段。例外是例外。这意味着，根据您正在使用的特定环境，对常规控制流使用异常可能导致：

• 效率低下环境为了安全地执行异常所需的相对困难的上下文更改而必须跳过环境的额外障碍，这需要工具和资源。

• 调试困难有时有用（在尝试调试程序时），当发生异常时，信息会丢出窗口。您可能会丢失与了解运行时行为有关的程序状态或历史记录

• 维护问题执行流程很难通过异常跳转来跟踪。除此之外，黑匣子类型代码内部可能会引发异常，而引发异常时，黑匣子类型代码的行为可能不容易理解。

• 糟糕的设计决策用这种方式构建的程序会激发一种思路，在大多数情况下，这些思路很难轻松地映射到优雅地解决问题的过程。最终程序的复杂性使程序员无法充分理解其执行，并鼓励做出决定，从而导致短期改进，而长期成本却很高。

我已经看到这种模式使用了几次。

有两个主要问题：

• 这是非常昂贵的（实例化异常对象，收集调用堆栈等）。某些编译器实际上可能能够对其进行优化，但是在这种情况下，我不会指望这一点，因为异常不是用于此类用途的，因此您不能指望人们为此进行优化。
• 使用异常进行控制流实际上是一个跳跃，很像goto。出于多种原因，跳跃被认为是有害的。如果所有替代方案都有明显的缺点，则应使用它们。实际上，在我所有的代码中，我只记得2种情况，其中跳转显然是最好的解决方案。

有时例外最快。我见过这样的情况：即使在Java中，空对象异常也比使用控制结构要快（我目前无法引用该研究，因此您必须信任我）。当Java必须花时间并填充自定义异常类的堆栈跟踪而不是使用本机异常类（似乎至少已部分缓存）时，就会出现问题。在说某些东西单方面更快或更慢之前，最好先进行基准测试。

在Python中，这样做不仅速度更快，而且做一些可能导致异常然后处理该错误的方法更为正确。是的，您可以强制执行类型系统，但是这与语言的原理背道而驰-相反，您应该简单地尝试调用方法并捕获结果！（测试文件是否可写是相似的-只需尝试写入文件并捕获错误）。

我见过一些时候，做一些愚蠢的事情（例如查询表）比找出一个表是否存在于PHP + MySQL中更快（我对它进行基准测试的问题实际上是我唯一接受的否定表决答案）。 。

综上所述，应出于以下几个原因限制例外的使用：

1. 误吞嵌套异常。这很重要。如果您发现某个嵌套嵌套的异常，而其他人正在尝试处理该异常，那么您就是在与其他程序员（甚至您！）开枪。
2. 测试变得不明显。一个代码块中有一个异常，可能有几处错误。另一方面，布尔值虽然理论上可能很烦人，但通常不是。这一点尤其正确，因为try...catch控制流的依附者通常（以我的经验）不遵循“尽量减少try块中的代码”的理念。
3. 它不允许有else if块。够用了（如果有人反对“但是他们可以使用不同的异常类”，我的回答是“去你的房间，除非你考虑了你所说的，否则不要出来。”）
4. 这在语法上是令人误解的。 Exception对于世界其他地区（不是对try...catch控制流哲学的拥护者），则意味着某事物已进入不稳定（尽管可能可恢复）状态。不稳定的状态是坏的，如果我们实际上有可以避免的例外情况，它应该使我们整夜都处于睡眠状态（它实际上使我无所适从，没有说谎）。
5. 它不符合常见的编码风格。我们的工作，无论是使用代码还是使用UI，都是为了使世界变得尽可能明显。try...catch控制流违反了通常认为的最佳实践。这意味着新来的人需要花费更多的时间来学习该项目，这意味着工时数的增加绝对没有任何收益。
6. 这通常会导致代码重复。最终块虽然不是严格必需的，但需要解决被中断的try块保持打开状态的所有悬空指针。因此，请尝试块。这意味着您可以拥有一个try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}。在更传统的if...else情况下，closeSomething()复制和粘贴工作的可能性较小（再次是个人经验）。（不可否认，这个特定的争论与我遇到的人更多的是关系，而不是实际的哲学本身）。

我的主要观点是使用try / catch进行逻辑操作会破坏逻辑流程。通过非逻辑结构遵循“逻辑”（对我而言）是违反直觉和令人困惑的。我习惯于将我的逻辑读为“如果条件则A否则B”。阅读与“尝试A捕获然后执行B”相同的语句感到很奇怪。如果语句A是一个简单的赋值，那将变得更加奇怪，如果它condition为false ，则需要额外的代码来强制执行异常（并且这样做可能if始终需要-statement）。

好吧，只是礼仪问题，在您声明“与他们开始争论”之前，我会问“为什么他们在所有这些不同地方都使用异常处理？”

我的意思是，有几种可能性：

1. 他们没有能力
2. 他们所做的事情完全有道理，乍一看可能不会出现。
3. 有时这是一个品味问题，可能会简化一些复杂的程序流程。
4. 这是过去的遗物，没有人改变过，如果有人这样做，他们会很高兴

...我认为所有这些可能性都是一样的。因此，很好地问他们。

Try Catch仅应用于异常处理。更重要的是，especific异常处理。您的try catch应该只捕获预期的异常，否则，它的格式不正确。如果您需要使用catch全部尝试catch，则可能是您做错了什么。

编辑：

原因：您可以辩称，如果将try catch用作条件运算符，那么您将如何考虑REAL异常？

例外是指发生例外情况时发生的情况。该程序是否按常规工作流程正常运行？

使用异常的原因：

1. 如果您忘记了遇到特殊情况，您的程序将会终止，并且堆栈跟踪会告诉您原因。如果您忘记为异常情况处理返回值，则不会告诉您程序将在多远的距离出现错误行为。
2. 仅当存在可以返回的前哨值时，才使用返回值。如果所有可能的返回值都已经有效，那么您该怎么办？
3. 异常将包含有关所发生事件的更多信息，这可能会有用。

不使用例外的原因：

1. 许多语言并非旨在快速创建例外。
2. 遍历堆栈多层的异常可能会在唤醒后留下不一致的状态

到底：

目的是编写传达正在发生的事情的代码。异常可以帮助/阻碍代码的运行。在python字典引用上尝试对KeyError进行try / catch非常完美（只要您知道该语言），对于距离五个函数层相同的KeyError进行try / catch是危险的。

在某些情况下，我使用try-> catch作为流控制。如果您的主要逻辑依赖于失败的事物，但是您不想只是抛出异常然后退出……那就是try-> catch块的目的。我写了很多不受监视的服务器端Unix脚本，对于它们来说，失败要比让它们彻底失败更重要。

因此，请尝试使用计划A，如果计划A死了，赶上计划B并运行...如果计划B失败，请最终使用它启动计划C，这将修复A或B或页面中失败的服务之一我。

它取决于语言，可能取决于所使用的实现。C ++中的标准是应为真正的异常事件保存异常。另一方面，在Python中，准则之一是“ 请求宽容比允许许可容易 ”，因此鼓励在程序逻辑中集成try / except块。

这是一个坏习惯，但我有时会用python来做。喜欢，而不是检查文件是否存在，我只是尝试将其删除。如果它引发异常，我会继续前进，直到知道它不存在。<==（如果另一个用户拥有该文件，则不一定正确，但是我在用户的主目录中执行此操作，因此应避免这种情况）。

但是，过度使用仍然是一种不好的做法。

我喜欢Apple 定义它的方式：异常仅适用于程序员错误和致命的运行时错误。否则使用错误代码。它帮助我决定何时使用它，对自己说：“这是程序员错误吗？”

这听起来像使用异常处理在没有goto命令的语言之上构建goto逻辑。

由于goto逻辑不好的多种原因，您可以参考以下问题：https : //stackoverflow.com/questions/46586/goto-still-considered-harmful