通過SQL Server代理在SSIS包中運行的C＃腳本有時會觸發調用目標拋出的異常

Question

我所知道的：第三方軟件在Java的后台運行。 我無法控制該軟件中的代碼。 它的工作是在外部服務器可用時立即從中獲取新的zip文件。 這些文件應該在0100之前進入，但第三方無法遵守此請求。 在0100， 我控制的任務（一個C＃腳本）運行以解壓縮已下載的文件，提取必要的文件，並將我們想要的文件壓縮回不同的位置，並刪除任何不必要的內容。 此程序設置為運行1小時並獲取已存在的任何文件，以及該小時內文件夾中顯示的任何文件。 這個程序編譯很好，在Visual Studio中運行良好，並且通常通過SQL Server代理成功運行完成。

有時雖然（例如，5次中的1-2次），但它會失敗，並帶有微妙的消息“調用目標已拋出異常”。

我的理論：來自第三方的zip文件非常小。 平均可能80-90KB。 它們通常在不到一秒鍾內下載。 然而，我和我的同事懷疑基於SSD的服務器足夠快，以至於我們制作的程序運行以解壓縮目標文件夾中的任何內容，有時它會選擇一個當前的zip文件，無論如何簡單，由第三方下載者“占領”，甚至未完成。 這導致我們的程序崩潰，因為它無法訪問zip文件。

（我不會在這里粘貼代碼，因為因為這個程序通常運行良好我看不到代碼是問題）。

我認為可能是這種情況的原因之一是該任務設置為如果失敗則重試一次。 有時它會在重試時運行完成，有時它會在10秒到20分鍾之間運行，然后再次崩潰。 由於第二個作業設置為在當晚晚些時候開始，因此我們無法將此任務設置為在失敗時重新運行多次。

最好的解決方案是改變第三方程序在某些時間暫停，但我們無法對此程序進行這些改動。 我們也不確定如果我們在0100設置一個計划任務來終止這個進程會發生什么。如果這個程序當前正在下載一個zip文件，我們冒這個文件被破壞的風險，這只會導致我們的解包任務失敗再次。

我們考慮的第二個解決方案是在程序中添加try-catch子句以捕獲此異常，我們使程序等待1或2秒，然后重試。 問題是我們似乎找不到強制轉換的特定異常類型。 據我所知，可能沒有一個。 我認為可以做到的唯一方法是制作一個通用的catch-any-exception子句，其中重試是在內部進行的。 然而，這意味着在少數損壞的zip文件到達的情況下，我們只會看到無限循環。

我在問什么： - 有誰知道這類問題正在引發什么特定的例外？ （如果有的話）。 - 為什么try-catch-wait（1）方法是一種非常糟糕的方法？

Answer 1

除了你已經做過的事情之外，沒有其他人能夠比你更了解你的異常，最好的方法是使用Try-Catch並創建更強大的錯誤處理。