为什么main()中的try-catch不好？

Question

有人可以向我解释为什么在main()方法中有一个try-catch来捕获任何未处理的异常是不合适的吗？

[STAThread]
static void Main()
{
    try
    {
        Application.Run(new Form1());
    }
    catch (Exception e)
    {
         MessageBox.Show("General error: " + e.ToString());
    }
}

我知道这是不好的做法,但不确定原因.

Answer 1

我认为这不一定是不好的做法.但是有一些警告......

我认为,任何称之为"不良做法"的人都强调你应该捕捉最接近它们出现位置的异常的想法(即尽可能高的调用堆栈/适当的).一揽子异常处理程序通常不是一个好主意,因为它大大减少了可用的控制流.粗粒度异常处理非常重要,不是程序稳定性的合理解决方案.不幸的是,许多初学者开发人员认为它是,并采取这种方法,如这个毯子try-catch语句.

这样说,如果你在程序的其余部分中正确使用了异常处理(以细粒度和任务特定的方式),并相应地处理了错误(而不是juist显示一般错误框),那么一般尝试-catch用于Main方法中的所有异常可能是有用的.这里需要注意的一点是,如果你可重复地捕获这个Maintry-catch中的bug,那么你有一个bug或者你的本地化异常处理有问题.

这个try-catch的主要用途Main纯粹是为了防止你的程序在非常特殊的情况下崩溃,并且几乎不应该向用户显示(模糊的)用户友好的"致命错误"消息,以及可能在某处记录错误和/或提交错误报告.总而言之:这种方法确实有其用途,但必须非常谨慎地完成,而不是出于错误的原因.

Answer 2

好吧,这个方法只会捕获主线程中抛出的异常.如果您同时使用Application.ThreadException和AppDomian.UnhandledException事件,那么您将能够捕获并记录所有异常.

Answer 3

我根本看不出那种糟糕的做法.

让程序因未处理的异常错误而崩溃,不会给最终用户带来任何信心.

也许其他人可以提供反制视图.

更新:显然你需要做一些有用的例外.

1. 记录下来
2. 向用户显示一个对话框,说明应用程序退出的原因(以纯文本形式,而不是堆栈跟踪)
3. 在您的应用程序的上下文中有意义的其他东西.

Answer 4

我不认为这本身就是一种不好的做法.我认为不好的做法是,如果那是你应用程序中唯一的try/catch块.

Answer 5

任何异常Main()都可能是致命的.

如果它很容易,它应该被处理得更高.如果这是你无法控制的事情OutOfMemoryException,那么程序就会崩溃.

崩溃的Windows应用程序有一个标准的方法,它们会触发Windows错误报告对话框.(你以前很可能已经看过了).发生这种情况时,您可以注册接收崩溃数据.

Answer 6

在古代,在C++中放置一个try/catch会导致相当沉重的性能损失,并且在main周围放置一个将意味着为所有内容存储额外的堆栈信息,这再次对性能有害.

现在计算机速度更快,程序员对性能不那么沉迷,而且运行时间更好,所以它不再那么糟糕了(但是你可能会为它付出更多的代价,多年来没有对它的效果进行基准测试).所以这是一种古老的民间传说,就像在对抗谷物一样(编译器现在无论如何都会为你修复迭代).在C#中它完全没问题,但是对于10年前的某个人来说它看起来很不错.