滥用 try/catch [关闭]

Question

有时我觉得我在滥用 try/catch 公式。 也许我只是对良好的编码实践偏执，但我想知道，您是否认为使用 try catch 来避免临界崩溃情况是个坏主意？

让我解释一下：假设您有一些东西随着时间的推移而改变，并且您知道它可能会发生被零除或数组超出范围异常的情况。 很多时候，在这种情况下您唯一要做的就是用return; 关闭方法。这需要尝试了解异常会在哪些情况下发生，然后在这些情况下返回。

在许多情况下，这可能是一项痛苦的任务，而此时我只是简单地捕捉到发生的事情并返回。

        if (/* Potentially multiple peinful search for crashing points*/)
            return;

我愿意

        try
        {
            //I know it's going to crash here sometimes
        }
        catch { return; }

有时这很方便，但感觉有点作弊。 举个例子：我只是用两个相互交互的 TrackBar 编写一个东西，在某些情况下，如果将两者中的一个带到 Min 或 Max 它将创建除以零。我很高兴 UI 在崩溃前停留在 ValueChanged 事件中，所以这个解决方案就可以了。

您对此有何看法？它被认为是某种可怕的编码事情，还是人们这样做？

Answer 1

好吧，try/catch 有 try 的想法，如果出现问题，catch 异常。当你捕捉到异常时，如果你只是隐藏错误，你永远不知道你的系统发生了什么。

例如：如果您在方法中放置了 try/catch 以避免被零除，并且当用户在输入中输入零时您有一个验证，如果有一天这个验证停止工作，您将永远不知道发生了什么与你系统。这可能会在未来导致另一个问题，更大，修复成本更高。

所以，我的建议是：您可以使用 try/catch 来处理很多操作系统问题，以避免屏幕上出现丑陋的错误或系统崩溃，但您必须设法存储异常，并且如果可能的话，警告你。 我有操纵消息并向用户显示的习惯，例如：

“系统发生错误。请向支持人员发送消息，代码错误：ER23421”。

我将异常与错误代码一起存储在日志文件中（这只是文件上的索引，最容易找到日志）。

所以，你可以使用 try/catch，但永远不要排除系统的异常。

Answer 2

您基本上使用 try and catch 块来提供对异常的正确处理。

换句话说，以下是捕获错误时“正确处理异常”的示例：

• 将其记录下来，以便将来增强您的产品，
• 您通知用户例如发生了错误
• 给出一个有意义的信息如何处理这个错误
• 将用户重定向到不同的页面或 UI 或继续执行程序的工作流程。

这只是一个例外，现在如果您正在执行 try catch 块来阻止程序崩溃，而没有有意义的处理过程，对您的代码没有意义，您应该添加额外的过程。

Answer 3

• 当您期望异常时，它是滥用。
• 当您控制程序流时，这是滥用。
• 当您不处理异常时，就是滥用。
• 如果您只是不想进行适当的测试，那就是滥用。

这里有 3/4。不是偏执狂；代码味道。