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; }

有时这是非常好的，但感觉有点像作弊。举个例子：我只是用两个TrackBars相互交互来编写一个东西，在某些情况下，如果两个中的一个被带到Min或Max，它会创建一个除零。我很高兴在崩溃前留在ValueChanged事件的用户界面，所以这个解决方案没问题。

您如何看待这个？它被认为是某种可怕的编码事物，还是人们这样做？

Answer 1

好吧，try / catch有尝试的想法，如果出现问题，捕获异常。当您捕获异常时，如果您只是隐藏错误，您永远不会知道您的系统有什么好处。

例如：如果你在方法中放置一个try / catch以避免被零除，并且当用户在输入上放零时你有一个验证，如果有一天这个验证停止工作，你永远不会知道什么是幸福的与你的系统。这可能导致未来出现另一个问题，更大，也更昂贵。

所以，我的最大信息是：你可以使用try / catch来获取很多东西，以避免屏幕上出现丑陋的错误，或者系统崩溃，但你必须设法存储异常，如果可能的话，警告你。我有自定义操作消息并为用户显示，如下所示：

“系统出现错误。请发送一条消息，告知支持代码错误：ER23421”。

我将异常存储在日志文件中，并带有错误代码（这只是文件的索引，以便最容易地找到日志）。

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

Answer 2

您基本上使用 try和catch block 来正确处理异常。

换句话说，这是＆＃34; 正确处理异常＆＃34;的示例当你发现错误时：

这只是一个例外，现在如果你正在尝试使用catch块来阻止你的程序崩溃，没有有意义的处理过程，对你的代码没有任何意义，你需要来添加额外的过程。

Answer 3

这里有3/4。不偏执;代码闻起来。