問題描述

通常我將我所有的 Main 方法代碼放在一個 try/catch 塊中，如下所示:

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?

推薦答案

在 try/catch任何段代碼> 沒有充分理由的阻止是不好的做法.

在 .NET 編程模型中，應為真正的異常情況或條件保留異常.您應該僅嘗試捕獲您實際上可以做某事的異常.此外，您不應該永遠捕獲基本的 System.Exception 類(而是更愿意捕獲您可以的更具體的派生異常類處理).如果在您的程序執行過程中遇到真正意外的異常，您實際上應該崩潰.

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.

顯然，正確"的答案必須根據具體情況做出，具體取決于 catch//code 占位符內部發生的情況> 阻止.但是，如果您要求一般規則或最佳實踐"，您應該始終有一個特定的理由來捕獲異常，而不僅僅是將所有代碼包裝在一個巨大的 try/catch 理所當然地阻塞而不考慮它.

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.

請注意，如果您只是為了記錄日志或錯誤報告而嘗試捕獲任何可能發生的未處理異常，則應該使用 AppDomain.UnhandledException 事件.這是一個僅通知事件，因此它不允許您處理這些異常，但它是在應用程序崩潰后實現日志記錄或錯誤報告功能的正確位置.

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.

當我正在閱讀 Raymond Chen 的優秀博客時，舊新事物"，我注意到他最近發表了一篇關于類似主題的文章.它特定于 COM，而不是 .NET Framework，但有關錯誤處理的一般概念同樣適用于這兩種環境.我想我會在這里分享這篇文章中的一些精華，以支持我的[顯然頗有爭議]的觀點.

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.

從歷史上看，COM 在服務器的方法周圍放置了一個巨大的 try/except.如果您的服務器遇到通常未處理的異常，巨大的 try/except 會捕獲它并將其轉換為錯誤 RPC_E_SERVERFAULT.然后它將異常標記為已處理，以便服務器保持運行，從而即使遇到問題也能保持服務器運行，從而提高魯棒性."

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.

您可以 [并且應該] 在他的博客上閱讀整篇文章:如何關閉 COM有用地"包裹在服務器周圍的異常處理程序.

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 中:這是不好的做法嗎?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！