在這種情況下使用System.Exception是否合適？

Question

通常它不喜歡使用System.Exception，但我想知道這是否是我唯一的選擇。

我有這樣的情況下編輯

權限檢查完成

1. 用戶請求的任務。
2. 如果全部都是良好的db任務行檢索
3. 然後提交該任務的更新並更新列以表明它已被鎖定。
4. 一些時區的東西被應用到這個任務將日期轉換爲本地時間。
5. 任務顯示給用戶。

因此，如果在步驟1到步驟4之間發生任何事情，任務仍然很好，因爲它沒有鎖定。但是，如果在步驟5中失敗，並且我無法將任務顯示給用戶，則該文件將被鎖定，並且會一直鎖定，直到計劃的作業運行，以確保鎖定爲long的文件被強制解鎖。

這種情況並不理想，因爲它可能會暫時失敗，下一次他們請求文件時可能會再次運行。但是現在他們必須等待（與所有其他訂戶相同）X分鐘，直到它自動解鎖。

因此，我的第一個想法是使用最後的聲明，但無論如何，這總是得到運行，所以我無法弄清楚如何說好文件現在被鎖定，不要打開它解鎖。

或者該文件被鎖定，但出現問題解鎖它。如果C＃有一個只在發生異常時才運行的語句，那將會很好。

所以我唯一的想法是有一個異常，如果發生任何事情，它會在那裏解鎖它。唯一的情況是，如果它是一個SQl異常，因爲如果數據庫關閉，沒有任何一點試圖解鎖某些東西。

當然，我會用elmah來記錄錯誤並緩慢地添加更好的異常類型，因爲它們會發生。

那麼有沒有人有更好的想法？

Answer 1

不要讓完美成爲好的敵人。在這種情況下捕捉一般異常是非常好的。如果您可以捕獲並從更具體的異常類型中恢復，請執行此操作。但擁有一切即將到來的地獄恢復計劃不僅可以，而且值得稱讚。

Answer 2

捕捉System.Exception是可以接受的，如果它是一個線程的頂部，並且你不希望你的程序在任何情況下崩潰。一般來說，捕捉System.Exception是一個壞主意，因爲您應該對可能發生的錯誤有一些瞭解，例如當發生完全意想不到的事情時，它會冒泡到您的線程的頂部，在那裏捕獲System.Exception並可能提供堆棧跟蹤信息等用於調試目的。在你的情況中，由於你擔心在處理時區轉換的第5步中發生的「不好的事情」，你可以嘗試預測哪些特定的異常或異常類可能會在那裏觸發，特別是捕捉它們，處理適當解鎖。

另外，因爲你顯然有能力創建所述計劃的任務，其中發現鎖定的文件，並有效地強制解鎖，你不能在你的finally塊中使用相同的邏輯嗎？例如如果它被鎖定，解鎖它，否則，noop。