c# - 滥用 try/catch

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

4年前关闭。




Improve this 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 有 的想法试试一些东西，和捕获 如果出现问题，则异常(exception)。当你捕捉到异常时，如果你只是隐藏错误，你永远不知道你的系统发生了什么。

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

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

“系统发生错误。请发送消息以获取支持，代码错误:ER23421”。

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

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