通过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并创建更强大的错误处理。