当被要求修复程序中的错误时，你会发现超过100个实例
catch(Exception ex) { } 什么是最好的方法？
将它们全部撕掉并让它崩溃？ 添加日志代码？ 留言箱？ 这是在C＃中。
这在一定程度上取决于你的积极程度。 此应用是内部还是外部？ 您的更改是否会很快部署在实时系统上？ 您是否有特定的错误需要修复，或者它只是被视为灾难？
为了尽可能快地减少错误数量，但是最大的风险是严重损坏，只需删除所有捕获块并让exception冒泡。 对于更精细的方法，只需添加日志记录即可。
如果可能的话，您还应该与编写应用程序的人交谈。 试着找出为什么他们有这么多exception吞咽障碍。 他们真的了解exception吗？ 这里需要一定的机智，我怀疑:)
下一站：unit testing……
修复您设置的错误，并将exception吞咽块报告为新的，关键的错误。
第一个中间目标是很好地了解哪些例外被忽略以及在哪里; 为此，您可以简单地将日志记录代码添加到每个可怕的catch -everything块中，准确显示它是什么块，以及它捕获和隐藏的内容。 对如此检测的代码运行测试套件，您将获得修复作业的起始“蓝图”。
如果你没有测试套件，那么，首先，让一个unit testing可以等待（查看Feathers关于使用遗留代码的好书 – 遗留代码绝对是你的问题;-)，但是你需要一套可以自动运行的集成测试，并解决你应该修复的所有错误。
当你去修复bug之后的bug（许多不是由过于宽泛的catch块造成的，只是隐藏 /“推迟”他们;-)，一定要以大多数“测试驱动”的方式工作：添加一个unit testing，检查错误，确认它中断，修复错误，重新运行unit testing以确认错误消失。 您不断增长的unit testing套件（一切可能被模拟或伪造）将快速运行，您可以在工作时保持廉价重新运行，尽快捕捉可能的回归，当它们仍然易于修复时。
您所分配的任务实际上比“高声望”的SW开发任务（例如原型和新架构）更难（通常更重要），但经常被管理层误解和不充分（并因此得不到奖励！） /客户端; 确保与利益相关者保持一个非常清晰和开放的沟通渠道，指出你正在做的所有大量成功的工作，它是多么具有挑战性，并且（为了他们的缘故，比你自己更多），他们将拥有多少通过在第一时间做到这一点来保存（也许下次他们会……我知道，我天生就是一个狂热的乐观主义者;-)。 也许他们甚至会为您分配任务的合作伙伴，然后您可以进行代码审查和配对编程，从而极大地提高工作效率。
并且，最后但并非最不重要的， 祝你好运！ – 不幸的是，你需要它……幸运的是，正如杰斐逊所说，“我工作越努力，我似乎就越幸运了”;-)
更改catch块如下：
catch (Exception ex) { Logger.Log(String.Format( System.Globalization.CultureInfo.InvariantCulture, "An exception is being eaten and not handled. "+ "This may be hiding critical errors.\n"+ "Exception: {0}", ex)); }
哇….
我会犹豫要把它们撕掉，因为赔率只会造成更多的“错误”。 第一步是添加日志记录，以便您知道发生了什么。 在您有足够的信息后，您将能够进行重构….
unit testing将是测试任何重构的好方法。 我还建议让它们到位。
您应该选择的解决方案在很大程度上取决于您所处的环境。
我编写并向大多数客户介绍的编码指南，明确指出没有评论的空捕获条款（正如您在问题中所示）可以在没有任何讨论的情况下删除。 我写这条规则的原因是因为我一直遇到这种语句，它们几乎总是隐藏很多错误。 通常，try块中的代码越多，它们隐藏的错误就越多。 多年来，我通过简单地删除空catch子句来发现（并解决了）很多错误。 程序通常是相同的：
- 我删除了一个捕获。
- 代码进入生产阶段。
- 经过一段时间客户投诉该程序停止工作（他有例外）。
- 我开始调查这个问题并发现系统的这一部分从未真正起作用，并且多个开发人员试图找到与此原因相关的错误，但从未发现问题。 或者更糟糕的是，他们发现了问题并编写了catch语句来“解决”问题。
- 我解决了在地毯下扫过的真正问题并立即关闭多个错误报告。
虽然这种方法在这些年里为我（以及我的客户）提供了很好的服务，但是有一个’但是’。 例如，我目前的一个客户是医疗机构，开发人员有兴趣使用我的编码指南。 但是，我坚持要求他们从准则中删除该特定规则。 虽然他们的软件中有很多空的catch语句（远远超过100），但那些讨厌的东西会隐藏很多错误，并且在我使用他们的软件时会一直记录下来。 你必须在这些类型的应用程序中非常小心。 在这种情况下，我将首先添加日志语句，而不是删除它们。 在此之后，当您知道发生了哪些类型的exception以及之前的开发人员为什么首先添加了catch语句时，您可以逐个缓慢地删除它们。
在所有情况下，您应该在应用程序的顶部有一个常规catch语句（或者在Web应用程序中有一个exception处理程序），它将记录任何冒泡的exception。
另外请注意，我的指南还指出，您将配置Visual Studio以中断所有exception，方法是转到Debug / Exceptions … / Common Language Runtime Exceptions并选中’Thrown’复选框。 这样您就可以立即发现exception。
警告：这是一般建议，你环境中的怪癖可能使它变得不可能，例如时间压力。
除了在系统的入口点（主要方法，服务端点，线程调用堆栈顶部，事件处理程序 – 用于UI代码）之外，将它们全部删除，并将日志记录/error handling添加到exception处理程序保留的位置。
开始一个将处理程序添加回所需位置的过程，即应该通过适当的日志记录/错误报告来处理exception应该降低的位置。
使系统再次运行取决于是否有一组良好的验收/回归测试，以在完成所有更改后validation系统是否正确。
显然，记录所有被抑制的exception是第一个开始的地方 – 当你需要确保你的代码在所有情况下正常降级时（即你不希望被exception类型捕获的情况），毯式抑制是有用的。你没有预料到），但是可以隐藏一个需要更多处理的意外问题，而不仅仅是被忽略，所以所有exception处理程序都必须至少报告一个exception被抑制，所以你有一个清晰的线索到如果出现意外行为，请关注。
删除捕获是愚蠢的，因为在许多情况下需要“处理”一些例外以使程序正常工作（尽管您可能不同意它们的处理方式，并且可能存在与此方法相关的风险，原始作者有理由以这种方式编写代码.Ig他没有添加评论解释他的理由，然后不要假设你比他更了解，特别是不是以“全局搜索和替换”的方式。
但是，似乎没有人指出最明显，最快的实现起点：转到“Debug – > Exceptions”并为“Common Language Runtime Exceptions”部分启用“ 抛出exception时中断”。 这将导致调试器针对抛出的每个exception（在调用程序的catch块来处理它之前）中断，因此您将能够在调试器下测试应用程序并确定哪些catch块在您尝试时抑制哪些exception重复给定的错误，然后您可以从中判断该特定的捕获块是否对所讨论的错误有任何影响。
为了获得正在发生的事情，您可以采取的一种方法是获取每个空的Exception块，并让每个块调用方法breakOnException(Exception e) 。
除了（比如）记录它之外，此方法不必执行任何操作。 然后，您可以在具有此方法断点的调试器下运行该程序，并监视要触发的断点，然后调查原因。 不幸的是，这是一个劳动密集型的。
您是否有可以针对调试器中的代码运行的unit testing？ 用这些做上述事情是有意义的。