主要方法代码完全在try/catch中:这是不好的做法？

Question

通常我将所有Main方法代码放在try/catch块中,如下所示:

public static void Main(string[] args)
{
   try
   {
      // code
   }
   catch (Exception e)
   {
      // code
   }
}

我这样做是为了防止任何异常设法从程序逻辑的其余部分中滑出,从而允许我对它做一些事情,例如将其显示到控制台,将其记录到文件等等.但是,我被告知这是不好的做法.

你认为这是不好的做法吗？

Answer 1

没有充分理由在/ block中包装任何代码都是不好的做法.trycatch

在.NET编程模型中,应该为真正特殊的情况或条件保留例外.您应该只尝试捕获您可以实际执行某些操作的异常.此外,你应该应该很难永远抓住基础System.Exception类(而是更愿意抓住你更具体的,派生的异常类可以办理).如果在程序执行过程中遇到真正意外的异常,你实际上应该崩溃.

显然,"正确"答案必须根据具体情况进行,具体取决于块中// code占位符内部的内容catch.但是如果你要求一般规则或"最佳实践",你应该总是有一个特定的理由来捕获异常,而不是仅仅将你的所有代码包装在一个巨型try/ catch块中而不考虑它.

请注意,如果您只是想捕获为了记录或错误报告而可能发生的任何未处理的异常,那么您应该使用该AppDomain.UnhandledException事件.这是一个仅通知事件,因此它不允许您处理这些异常,但它是在应用程序崩溃后实现日志记录或错误报告功能的正确位置.

编辑:当我正在阅读Raymond Chen的优秀博客"The Old New Thing"时,我注意到他最近发表了一篇关于类似主题的文章.它特定于COM,而不是.NET Framework,但有关错误处理的一般概念同样适用于这两种环境.我想我会从这篇文章中分享一些宝石,以支持我[显然颇具争议的]意见.

从历史上看,COM放置了一个巨大的尝试/除了你的服务器的方法.如果您的服务器遇到通常是未处理的异常,那么巨型try/except会捕获它并将其转换为错误RPC_E_SERVERFAULT.然后它将异常标记为已处理,以便服务器保持运行,从而"通过在服务器遇到问题时保持服务器运行来提高健壮性".

请注意,这实际上是一种伤害.

发生未处理的异常这一事实意味着服务器处于意外状态.通过捕获异常并说"不要担心,这一切都很好",最终导致服务器运行损坏.

[...]

捕获所有异常并让进程继续运行假定服务器可以从意外故障中恢复.但这很荒谬.你已经知道服务器是不可恢复的吐司:它崩溃了!

更好的是让服务器崩溃,以便在故障点捕获崩溃转储.现在你有机会弄清楚发生了什么.

您可以[并且应该]在他的博客上阅读整篇文章:如何关闭COM"帮助"包装服务器的异常处理程序.

Answer 2

如果你正在做出最聪明的事情就可以解决错误,这是很好的做法.这就是try/catch的用途.

如果你只是抛弃错误(或者记录它并扔掉它) - 特别是如果你这样做而不管异常的类型 - 这被认为是不好的做法.

这可能会引发一个问题:如果最聪明的事情就是记录并扔掉它会怎么样？我想说这将是一个例外情况.但实际上,我的代码会断言.我想我沉迷于很多不好的做法.