在try-catch中包含服務執行：不好的做法？

下面是一個Windows服務程序通常Program.cs的內容：在try-catch中包含服務執行：不好的做法？

static class Program 
{ 
    /// <summary> 
    /// The main entry point for the application. 
    /// </summary> 
    static void Main() 
    { 
     ServiceBase[] ServicesToRun; 
     ServicesToRun = new ServiceBase[] 
     { 
      new MyService() 
     }; 
     ServiceBase.Run(ServicesToRun); 
    } 
}

它是一個不好的做法，封裝在一個try-catch塊ServiceBase.Run(...)？

謝謝。

編輯：

進行了一些測試，發現（試驗方法：發送自定義命令到服務，這將引發ApplicationException的在OnCustomCommand覆蓋）：

A.圍ServiceBase try/catch中的.Run（）不會捕獲OnCustomCommand中引發的異常，因爲當服務線程開始執行時try塊已經在範圍內。因此，質疑這種方法的正確性只要不能滿足其目的就無關緊要。

B.爲AppDomain.CurrentDomain.UnhandledException添加處理程序也沒有捕獲到異常。

但是，在這兩種情況下，都會在Windows事件日誌中顯示異常。這幾乎解決了我需要知道服務執行期間何時崩潰的問題，但問題仍然存在：有沒有什麼情況下服務可能會在事件日誌中沒有任何跟蹤的情況下悄然崩潰？

來源

2010-05-10 Sorin Comanescu

這取決於你在做什麼。如果你打算處理異常並對他們做一些有用的事情（例如重試，運行備份，通知用戶並要求反饋等），那麼國際海事組織我不認爲這是一種不好的做法。

正如我所說，這取決於你在做什麼。

來源

2010-05-10 08:41:32

該服務的主要方法充滿了try-catches，但即使如此，服務似乎意外關閉（我說「似乎」，因爲我真的不知道它是崩潰還是被某人手動攔截;它在不同的，相當孤立的環境中運行）。我想添加圍繞ServiceBase.Run（）的try-catch塊，只是爲了能夠區別停止/崩潰，但我不確定這是否是長時間運行的進程的有效設置。 – 2010-05-10 08:53:16

這個設置確實很脆弱。您將必須檢查特定的異常情況，以瞭解服務何時停止以及何時崩潰，但您也會發現其他異常情況。如果您的服務位於遠程計算機上並且網絡崩潰，那麼您的服務不會停止，也不會崩潰。爲您的服務添加記錄信息到OnStop，OnShutdown等方法，並讓它記錄發生的情況;也許如果你發現服務到底發生了什麼，你會從事情中獲得新的視角。 – 2010-05-10 09:53:57

在try-catch中包含服務執行：不好的做法？

回答

相關問題