滥用 try/catch

Question

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

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

在很多情况下，这可能是一项痛苦的任务，此时我只是简单地了解发生了什么，然后 return。

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

我愿意

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

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

你怎么看这件事？它被认为是某种可怕的编码事情，还是有人这样做？

Answer 1

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

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

所以，我的建议是：你可以使用 try/catch 做很多事情 os 来避免屏幕上出现丑陋的错误，或者系统崩溃，但你必须想办法存储异常，并且，如果 possible，警告你。我习惯于操纵消息并向用户显示，类似这样的事情：

"An error ocurred on the system. Please, send a message for the support with the code error: ER23421".

并且我将异常和错误代码存储在日志文件中（这只是文件上的索引，以便轻松找到日志 most）。

因此，您可以使用try/catch，但切勿排除系统异常。

Answer 2

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

换句话说，这里有一个当你发现错误时“正确处理异常”的例子：

登录以供将来改进您的产品，
例如，您通知用户发生了错误
给出一个有意义的信息，说明如何解决这个错误
将用户重定向到不同的页面或 UI 或继续您程序的工作流程。

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

Answer 3

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

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

滥用 try/catch

Abusing try/catch

c#

crash

try-catch