在 没有充分理由的情况下将 任何 代码包装在try/ catch块中都是不好的做法。

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

显然，“正确”的答案必须根据具体情况而定，具体取决于块中该// code占位符内部的情况catch。但是，如果您要寻求一般规则或“最佳实践”，则应该始终有捕获异常的特定原因，而不是理所当然地不只是将所有代码包装在一个大的try/
catch块中。

请注意，如果您只是试图捕获可能出于记录或错误报告目的而发生的任何未处理的异常，则应使用AppDomain.UnhandledExceptionevent。这是一个仅通知事件，因此不允许您 处理
这些异常，但是在应用程序崩溃后，它是实现日志记录或错误报告功能的正确位置。

编辑： 当我赶上阅读雷蒙德·陈（Raymond
Chen）出色的博客“旧事物”时，我注意到他最近发表了一篇有关类似主题的文章。它特定于COM，而不是.NET
Framework，但有关错误处理的一般概念同样适用于两种环境。我以为我在这篇文章中可以分享一些宝石，以支持我的[显然颇有争议的]观点。

从历史上看，COM围绕服务器的方法进行了巨大的尝试/例外。如果您的服务器遇到通常是未处理的异常，巨型try /
except将捕获该异常并将其变为error
RPC_E_SERVERFAULT。然后将异常标记为已处理，从而使服务器保持运行状态，从而“即使遇到问题也可以通过保持服务器运行状态来提高鲁棒性”。

提醒您，这实际上是一种伤害。

发生未处理的异常的事实意味着服务器处于意外状态。通过捕获异常并说“不用担心，这一切都很好”，您最终使损坏的服务器处于运行状态。

[。。。]

捕获所有异常并让进程继续运行，假定服务器可以从意外故障中恢复。但这是荒谬的。您已经知道服务器是无法恢复的吐司：它崩溃了！

更好的方法是让服务器崩溃，以便可以在故障点捕获崩溃转储。现在，您将有很大的机会了解正在发生的事情。

您可以[并且应该]在他的博客上阅读整篇文章：如何关闭COM“有帮助地”包装在服务器周围的异常处理程序。