主要方法代码完全在try / catch中：是不好的做法吗？ [英] Main method code entirely inside try/catch: Is it bad practice?

问题描述

通常我把所有的Main方法代码放在一个try / catch块中，如下所示：

  public static void Main （string [] args）
 {
 try 
 {
 // code 
} 
 catch（异常e）
 {
 //代码
} 
} 
  

我这样做只是为了万一异常会从程序逻辑的其余部分中滑出来，从而允许我做一些事情，比如显示它到控制台，登录到文件等。但是我被告知这是不好的做法。 / p>

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

解决方案

在中尝试 / catch 块中没有正当理由的代码

在.NET编程模型中，应为特殊情况或条件保留异常。您只应该 尝试捕获您实际可以执行某些操作的异常。此外，您应该不应该捕获基础 System.Exception 类（但更倾向于捕获更具体的派生异常类，您可以>可以句柄）。如果程序执行过程中遇到一个真正意想不到的异常，您实际上应该崩溃。

显然，正确的答案将会必须根据具体情况进行设置，具体取决于您的 catch // code 占位符内的内容$ c>块。但是，如果您要求一般规则或最佳实践，您应该总是有一个特定的原因来捕获异常，而不仅仅是将所有的代码都包含在一个巨大的中。尝试 / catch block当然不用考虑。

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

---

编辑：当我在阅读Raymond Chen的优秀博客时，旧的新事物，我注意到他最近发表了一篇关于类似话题的文章。它特定于COM，而不是.NET Framework，但是关于错误处理的一般概念同样适用于这两种环境。我以为我会在这篇文章中分享一些宝石，以支持我（显然颇有争议的）意见。

COM放置了一个巨大的尝试/除了你的服务器的方法。如果您的服务器遇到通常是未处理的异常，那么巨人try / except会抓住它并将其转换为错误 RPC_E_SERVERFAULT 。然后它将异常标记为已处理，从而使服务器保持运行，从而即使遇到问题也能保持服务器运行，从而提高稳定性。

这实际上是一种损害。

发生未处理异常的事实意味着服务器处于意外状态。通过捕获异常并说：别担心，这一切都很好，你最终会丢失服务器运行。

[。 。 。 ]

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

更好的是让服务器崩溃，以便在故障点捕获故障转储。现在你有一个机会找出发生了什么。

你可以[并且应该]在他的博客上阅读整篇文章：如何关闭COM异常处理程序 绕你的服务器。

Usually I put all of my Main method code inside of a try/catch block like so:

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

I do this just in case any exceptions manage to slip out of the rest of the program logic, thus allowing me to do something about it, such as display it to console, log it to a file, etc. However, I have been told that this is bad practice.

Do you think it is bad practice?

解决方案

Wrapping any piece of code in a try/catch block without a good reason is bad practice.

In the .NET programming model, exceptions should be reserved for truly exceptional cases or conditions. You should only try to catch exceptions that you can actually do something about. Furthermore, you should should hardly ever catch the base System.Exception class (but rather prefer to catch the more specific, derived exception classes you can handle). And should a truly unexpected exception be encountered during the course of your program's execution, you actually should crash.

Obviously the "correct" answer would have to be made on a case-by-case basis, depending on what's going on inside that // code placeholder in your catch block. But if you're asking for a general rule or "best practice", you should always have a specific reason to catch exceptions, not just wrap all of your code in a giant try/catch block as a matter of course without thinking about it.

Note that if you're simply trying to catch any unhandled exceptions that might occur for the purposes of logging or error reporting, you should be using the AppDomain.UnhandledException event. This is a notification-only event, so it doesn't allow you to handle those exceptions, but it is the right place to implement your logging or error reporting functionality after your application has crashed.

---

EDIT: As I was catching up on my reading of Raymond Chen's excellent blog, "The Old New Thing", I noticed that he had recently published an article on a similar topic. It's specific to COM, rather than the .NET Framework, but the general concepts regarding error handling are equally applicable to both environments. I thought I'd share a couple of gems from the article here, in support of my [apparently quite controversial] opinion.

Historically, COM placed a giant try/except around your server's methods. If your server encountered what would normally be an unhandled exception, the giant try/except would catch it and turn it into the error RPC_E_SERVERFAULT. It then marked the exception as handled, so that the server remained running, thereby "improving robustness by keeping the server running even when it encountered a problem."

Mind you, this was actually a disservice.

The fact that an unhandled exception occurred means that the server was in an unexpected state. By catching the exception and saying, "Don't worry, it's all good," you end up leaving a corrupted server running.

[ . . . ]

Catching all exceptions and letting the process continue running assumes that a server can recover from an unexpected failure. But this is absurd. You already know that the server is unrecoverably toast: It crashed!

Much better is to let the server crash so that the crash dump can be captured at the point of the failure. Now you have a fighting chance of figuring out what's going on.

You can [and should] read the whole article here on his blog: How to turn off the exception handler that COM "helpfully" wraps around your server.

这篇关于主要方法代码完全在try / catch中：是不好的做法吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！