当被要求修复程序中的错误时,您会发现超过100个

这在一定程度上取决于你的攻击性。这个应用是内部的还是外部的?您的更改将很快部署到实时系统上吗?您是否有特定的bug需要修复,或者它只是一个灾难?

为了尽可能快地减少bug计数,但在最有可能造成严重损坏的情况下,只需移除所有捕获块并让异常冒泡。对于一个更为微妙的方法,只需从添加日志开始。

如果可能的话,你还应该和编写应用程序的人谈谈。试着找出答案 为什么? 他们有太多的例外吞咽障碍。他们真的了解例外吗?我想这里需要一定的机智。)

下一站:单元测试…

修复您要执行的错误,并将异常吞咽块报告为新的、关键的错误。

第一个中间目标是清楚地了解哪些异常会被忽略以及在哪里被忽略;为此,您可以简单地将日志代码添加到这些可怕的 catch -所有的东西都会阻塞,精确地显示它是什么阻塞,以及它捕获和隐藏了什么。在这样检测的代码上运行测试套件,您将获得修复作业的开始“蓝图”。

如果你不 有 一个测试套件,然后,首先,生成一个——单元测试可以等待(签出 Feathers' great book 在处理遗留代码时——遗留代码在这里绝对是您的问题;—),但是您需要一套集成测试,可以自动运行,并勾选您应该修复的所有错误。

当你去修复一个又一个错误的时候(很多不会 引起 通过过宽的挡块, 隐藏的 /由他们“推迟”;-)确保以“测试驱动”的方式工作:添加一个勾选错误的单元测试,确认它中断,修复错误,重新运行单元测试以确认错误已消失。您不断增长的单元测试套件(所有可能的模拟或伪造)将运行得很快,并且您可以在工作时继续廉价地重新运行,以便在仍然容易修复的情况下尽快捕获可能的回归。

你被分配的任务实际上比“高声望”的软件开发任务(如原型和新架构)更难(而且通常更重要),但常常被误解和低估(因此被低估了!)通过管理层/客户;确保与利益相关者保持一个非常清晰和开放的沟通渠道,指出你正在做的大量成功工作,这是多么具有挑战性,并且(为了他们而不仅仅是你自己的利益)他们一开始就做对了会节省多少(也许下次他们会……我知道,我天生是一个疯狂的乐观主义者;-)。也许他们甚至会给你指派一个合作伙伴来完成这项任务,然后你可以进行代码审查和结对编程,极大地提高了工作效率。

最后但并非最不重要的是, 祝你好运!!!! --不幸的是,你需要它…幸运的是,正如杰斐逊所说,“我工作越努力,我似乎就越幸运。”—)

更改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));
}

真的。。。。

我会犹豫不决地撕掉它们,因为很可能会产生更多的“错误”。第一步是添加日志,这样您就知道发生了什么。在您有足够的信息之后,您将能够继续重构……小心地

单元测试将是测试您所做的任何重构的好方法。我也建议把它们放在适当的地方。

您应该选择的解决方案很大程度上取决于您所处的环境。

我编写并向我的大多数客户介绍的编码准则明确指出,无注释的空catch子句(正如您在问题中所示)可以在不进行任何讨论的情况下删除。我写这条规则的原因是因为我经常遇到这样的语句,它们几乎总是隐藏很多错误。通常,try块中的代码越多,隐藏的错误就越多。多年来,我通过简单地删除空catch子句发现(并解决)了许多错误。程序通常是相同的:

1. 我取下一个钩子。
2. 代码进入生产。
3. 过了一段时间,客户抱怨程序停止工作(他得到了一个例外)。
4. 我开始调查这个问题,发现系统的这一部分从来没有真正起作用,并且有多个开发人员试图找到与这个原因相关的bug,但从来没有发现这个问题。或者更糟的是,他们发现了问题并编写了catch语句来解决问题。
5. 我修复了地毯下的实际问题,并立即关闭多个bug报告。

虽然这种方法近年来为我(和我的客户)提供了很好的服务,但还是有一种“但是”。例如,我目前的一个客户是一家医疗机构,开发人员对使用我的编码指南很感兴趣。但是,我坚持认为他们会从指南中删除这一特定的规则。虽然他们的软件有很多空的catch语句(远远超过100个),这些讨厌的东西隐藏了很多错误,并且在我使用他们的软件时一直对我发字节;但是在这些类型的应用程序中,您必须非常小心。在这个场景中,我将从添加日志语句开始,而不是删除它们。在这之后,当您知道发生了哪种类型的异常以及上一个开发人员最初添加了catch语句的原因时,可以逐个缓慢地删除它们。

在所有情况下,应用程序的顶部都应该有一个通用的catch语句(或者在Web应用程序中有一个异常处理程序),它将记录任何冒泡的异常。

另外,我的指导原则还注意到,您将通过转到调试/异常来配置Visual Studio以突破所有异常…/公共语言运行时异常并选中“引发”复选框。这样你马上就能发现一个例外。

警告:这是一般性的建议,你的环境中的怪癖可能会使它成为不可能,例如时间压力。

在系统的入口点(主要方法、服务终结点、线程顶部调用堆栈、事件处理程序-用于UI代码)将它们全部删除,并将日志记录/错误处理添加到异常处理程序保留的位置。

开始在需要时重新添加处理程序的过程,即在需要时降低处理异常的位置,并使用适当的日志记录/错误报告。

使系统再次工作取决于在进行所有更改之后,是否有一组良好的验收/回归测试来验证系统是否正确。

显然,记录所有被抑制的异常是第一个开始的地方——当需要确保代码在 全部的 环境(即,您不希望被您未能预料到的异常类型捕获的情况),但可以隐藏需要更多处理而不是被忽略的未预料到的问题,因此所有异常处理程序都必须至少报告异常已被抑制,这样您就有了清晰的线索线索线索。如果出现意外行为,应采取措施。

删除捕获是愚蠢的,因为在许多情况下,需要“处理”一些异常才能使程序正常工作(尽管您可能不同意 怎样 它们被处理,并且可能存在与此方法相关的风险,原始作者有理由以这种方式编写代码。如果他没有添加评论来解释他的原因,那就不要以为你比他知道得更好,尤其是在“全球搜索和替换”的方式下。

但是,似乎没有人指出最明显、最快实现的起点:转到“调试->异常”并启用“异常时中断”。 投掷 用于“公共语言运行时异常”部分。这将导致调试器针对抛出的每个异常中断(在调用程序的catch块来处理它之前),因此您可以在调试器下测试应用程序,并确定当您尝试重复给定的bug时,哪些catch块正在抑制哪些异常,然后从中进行判断调用,以便该特定的catch块是否对所讨论的bug有任何影响。

你可以采取的一种方法是把每一个空的 Exception 块,并让每个块调用一个方法 breakOnException(Exception e) .

这个方法不需要做任何事情,除了(说)记录它。然后,您可以在这个方法上有断点的调试器下运行程序,并监视要命中的断点,然后调查原因。不幸的是,这有点劳动密集。

您有可以对调试器中的代码运行的单元测试吗?这样做是有意义的。