blocks|key|2149358|text|这在一定程度上取决于你能有多积极。这个应用是内部的还是外部的？您的更改很快就会部署到实时系统上吗？您是否有特定的bug需要修复，或者只是被认为是一场灾难？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2149359|为了尽可能快地减少bug数量，但具有最大的严重损害风险，只需删除所有catch块，并让异常冒泡。要获得更精细的方法，只需添加日志记录即可。|2149360|如果可能的话，你也应该和写这个应用程序的人谈谈。试着找出为什么他们有这么多的异常吞噬块。他们真的理解异常吗？我怀疑，这里需要一定的机智:)|2149361|下一站:单元测试...|2149362|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It partly depends on how aggressive you can be. Is this app internal or external? Will your changes be deployed on live systems soon? Do you have specific bugs to fix, or is it just deemed to be a disaster?

To reduce the bug count as quickly as possible, but with the most risk of serious damage, just remove all the catch blocks and let exceptions bubble up. For a much more delicate approach, just add logging to start with.

You should also talk to whoever wrote the app to start with, if possible. Try to find out why they've got so many exception-swallowing blocks. Do they really understand exceptions at all? A certain amount of tact is necessary here, I suspect :)

Next stop: unit tests...

blocks|key|3556936|text|哇..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3556937|我会犹豫要不要把它们取出来，因为很有可能只会产生更多的“bug”。第一步是添加日志记录，这样您就可以知道发生了什么。在有了足够的信息之后，您就可以继续refactoring....carefully了|3556938|单元测试将是测试您所做的任何重构的好方法。我还建议将它们放在适当的位置。|3556939|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

wow....

I would be hesitant to rip them out because odds are that would just create more "bugs". A first step would be to add logging so you know what is going on. After you have sufficient information you would be able to proceed refactoring....carefully

Unit tests would be a great way to test any refactoring you do. I would also suggest getting plenty of them in place.

blocks|key|3556963|text|为了了解发生了什么，您可以采取的一种方法是获取每个空的Exception块，并让每个块调用一个方法breakOnException(Exception+e)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3556964|这个方法不需要做任何事情，除了(比如说)记录它。然后，您可以使用此方法上的断点在调试器下运行程序，并观察要命中的断点，然后调查原因。不幸的是，这有点劳动密集型。|3556965|您是否有可以针对调试器中的代码运行的单元测试？用这些来做上面的事情是有意义的。|3556966|entityMap^0|R|9|1D|T|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

One approach you could take in order to get a picture of what's going on would be to take each of the empty <code>Exception</code> blocks, and have each one call a method <code>breakOnException(Exception e)</code>. 

This method doesn't have to do anything except (say) log it. You can then run the program under a debugger with a breakpoint on this method and watch for the breakpoint to be hit, and then investigate the causes. Unfortunately that's a little labour-intensive.

Do you have unit tests that can be run against the code in the debugger ? It would make sense to do the above with these.

blocks|key|1336495|text|警告:这是一个一般性的建议，你的环境中的怪癖可能会使它变得不可能，例如时间压力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1336496|在系统的入口点(主方法、服务端点、线程顶部调用堆栈、事件处理程序-针对UI代码)将它们全部删除，并将日志记录/错误处理添加到保留异常处理程序的位置。|1336497|开始在需要的地方添加处理程序的过程，即，在适当的日志记录/错误报告中处理异常的地方。|1336498|让系统再次工作依赖于在所有更改完成后，有一组良好的验收/回归测试来验证系统的正确性。|1336499|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Caveat: This is general advice and quirks in your environment may make it impossible, e.g. time pressures.

Rip them all out with the exception of at the entry points to the system (main methods, service end points, top of thread call stacks, event handlers - for UI code) and add logging/error handling to the places where the exception handlers remain.

The begin a process of adding the handlers back in where required, i.e. places where exceptions should be handled lower down, with appropriate logging/error reporting.

Getting the system working again is dependent on having a good set of acceptance/regression tests to verify the system is correct after all the changes are made.

blocks|key|1336525|text|修复你要做的bug，并将吞噬代码块的异常报告为新的、严重的bug。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1336526|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Fix the bugs that you were set out to do, and report the exception swallowing blocks as new, critical, bugs.

blocks|key|1340639|text|第一个中间目标是很好地了解哪些异常被忽略以及在哪里被忽略；为此，您可以简单地将日志记录代码添加到每个可怕的catch-everything块中，从而准确地显示它是什么块，以及它捕获和隐藏了什么。在这样插入指令的代码上运行测试套件，您将拥有修复作业的起始“蓝图”。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1340640|如果您没有测试套件，那么，首先，创建一个测试套件--单元测试可以等待(查看使用遗留代码的Feathers'+great+book+--遗留代码肯定是您的问题所在；-)，但是您需要一套可以自动运行的集成测试，并且可以修复您应该修复的所有bug。|1340641|当你去修复一个又一个的bug时(许多错误不是由过宽的catch块引起的，只是被它们隐藏/“推迟”了；-)，确保以一种主要“测试驱动”的方式工作:添加一个记录bug的单元测试，确认它被破坏，修复bug，重新运行单元测试以确认bug已经消失。你不断增长的单元测试套件(所有可能的东西都是模拟的或伪造的)将运行得很快，你可以在工作时保持低成本地重新运行，以捕捉可能的回归ASAPs，当它们仍然很容易修复的时候。|1340642|分配给您的任务实际上比“高声望”的软件开发任务(如原型和新体系结构)更难(而且往往更重要)，但经常被误解和低估(因此奖励不足！)管理/客户；确保与利益相关者保持非常清晰和开放的沟通渠道，指出你正在做的大量成功的工作，它有多么具有挑战性，以及(为了他们而不是你自己)，他们从一开始就可以节省多少(也许下一次他们会...我知道，我天生就是一个狂热的乐观主义者；-)。也许他们甚至会在任务中为你指派一个合作伙伴，然后你就可以进行代码审查和结对编程，从而极大地提高生产力。|1340643|最后但并非最不重要的是，祝你好运！--不幸的是，你需要它...幸运的是，正如杰斐逊所说，“我工作越努力，我似乎就越幸运”；-)|1340644|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0131177052^0|1H|5|0|18|K|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@$9|Z|A|10|1|11]]|E|$]]|$1|H|3|I|5|6|7|12|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|13|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|14|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|O|$P|$5|Q|R|S|E|$T|U]]]]

The first intermediate goal is to get a good picture of what exceptions are being ignored and where; for that purpose, you can simply add logging code to each of those horrid <code>catch</code>-everything blocks, showing exactly what block it is, and what is it catching and hiding. Run the test suite over the code thus instrumented, and you'll have a starting "blueprint" for the fixing job.

If you don't have a test suite, then, first, make one -- unit tests can wait (check out <a href="https://rads.stackoverflow.com/amzn/click/com/0131177052" rel="noreferrer" rel="nofollow noreferrer">Feathers' great book</a> on working with legacy code -- legacy code is most definitely your problem here;-), but you need a suite of integration tests that can be run automatically and tickle all the bugs you're supposed to fix.

As you go and fix bug after bug (many won't be caused by the excessively broad catch blocks, just hidden/"postponed" by them;-), be sure to work in a mostly "test-driven" manner: add a unit test that tickes the bug, confirm it breaks, fix the bug, rerun the unit test to confirm the bug's gone. Your growing unit test suite (with everything possible mocked out or faked) will run fast and you can keep rerunning cheaply as you work, to catch possible regressions ASAPs, when they're still easy to fix.

The kind of task you've been assigned is actually harder (and often more important) than "high prestige" SW development tasks such as prototypes and new architectures, but often misunderstood and under-appreciated (and therefore under-rewarded!) by management/clients; make sure to keep a very clear and open communication channel with the stakeholder, pointing out all the enormous amount of successful work you're doing, how challenging it is, and (for their sake more than your own), how much they would have saved by doing it right in the first place (maybe next time they will... I know, I'm a wild-eyed optimist by nature;-). Maybe they'll even assign you a partner on the task, and you can then do code reviews and pair programming, boosting productivity enormously.

And, last but not least, good luck!!! -- unfortunately, you'll need it... fortunately, as Jefferson said, "the harder I work, the more luck I seem to have";-)

blocks|key|1336568|text|您应该选择的解决方案在很大程度上取决于您所处的环境。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1336569|我编写并介绍给大多数客户的编码指南明确指出，不带注释的空catch子句(正如您在问题中所显示的那样)可以在没有任何讨论的情况下删除。我写这条规则的原因是因为我总是遇到这样的语句，它们几乎总是隐藏着很多bug。通常，try块中的代码越多，隐藏的bug就越多。多年来，我通过简单地删除空catch子句来发现(并解决)了许多bug。步骤通常是相同的：|1336570|1336571|I删除了一个陷阱。|ordered-list-item|1336572|代码有时会被客户投诉程序停止工作(他得到了一个异常)。|1336573|我开始调查这个问题，并发现系统的这一部分从未真正工作过，许多开发人员试图找到与此原因相关的错误，但从未发现问题。或者更糟的是，他们发现了问题，并编写了catch语句来“解决”问题。|1336574|I修复了被掩盖的真正问题，并同时关闭了多个错误报告。|1336575|1336576|虽然这种方法这些年来对我(和我的客户)很有帮助，但也有一个“但是”。例如，我目前的一个客户是一家医疗机构，开发人员对使用我的编码指南很感兴趣。然而，我坚持他们会从指南中删除这一特定的规则。虽然他们的软件有非常多的那些空的catch语句(远远超过100条)，那些讨厌的东西隐藏了很多错误，在我使用他们的软件时一直在给我发字节；你在使用这些类型的应用程序时必须非常小心。在这个场景中，我将从添加日志语句开始，而不是删除它们。在此之后，当您知道发生了哪些类型的异常以及之前的开发人员为什么首先添加catch语句时，您可以逐个缓慢地删除它们。|1336577|在所有情况下，你都应该在你的应用程序的顶部有一个通用的catch语句(或者在你的web应用程序中有一个异常处理程序)，它将记录任何冒泡的异常。|1336578|另外，我的指导方针还指出，您可以通过转到Debug+/+Exceptions...将Visual+Studio配置为在所有异常时中断。/+Common+Language+Runtime+Exception(公共语言运行时异常)并选中“抛出”复选框。通过这种方式，您可以立即发现异常。|1336579|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|12|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

The solution you should pick depends greatly on the environment you're working in.

The coding guidelines I've written and introduced to most of my customers, state explicitly that empty catch clauses without comments (exactly as you've shown in your question) may be removed without any discussion. The reason I wrote this rule is because I encounter these kind of statements all the time and they almost always hide a lot of bugs. Usually, the more code is in the try block, the more bugs they hide. Over the years I have discovered (and solved) a lot of bugs by simply removing empty catch clauses. The procedure is usually the same:

<ol>
<li>I remove a catch.</li>
<li>Code goes to production.</li>
<li>After some time customer complaints that the program stopped working (he got an exception).</li>
<li>I start investigating the problem and find out that this part of system never really worked, and multiple developers have tried to find bugs related to this cause, but never found the problem. Or worse, they found the problem and wrote that catch statement to ‘solve’ the problem.</li>
<li>I fix the real problem that was swept under the carpet and close multiple bug reports at once.</li>
</ol>

While this method has served me (and my customers) well these years, there is a ‘but’. For instance, one of my current customers is a medical institution and the developers were interested in using my coding guidelines. However, I insisted that they'd remove that particular rule from the guidelines. While their software has a terribly lot of those empty catch statements (well over 100) and those pesky things hide a lot of errors and byte me all the time while I work with their software; you must be very careful in these types of applications. In this scenario, I would start by adding log statements, instead of removing them. After this you can remove them slowly one-by-one when you know which types of exceptions occur and why the previous developer did add that catch statement in the first place.

In all cases, you should have a general catch statement at the top of your application (or have an exception handler in your web app) that will log any exceptions that bubble up.

Extra note, my guidelines also note that you would configure Visual Studio to break on all exceptions, by going to Debug / Exceptions... / Common Language Runtime Exceptions and check the 'Thrown' checkbox. This way you spot an exception right away.

blocks|key|2149833|text|显然，记录所有被抑制的异常是第一个开始的地方-当你需要确保你的代码在所有情况下都优雅地降级时(即你不希望被你没有预料到的异常类型所捕获)，但是可以隐藏一个需要更多处理而不是简单地被忽略的意想不到的问题，所以所有异常处理程序至少应该报告一个异常已经被抑制，所以当出现意外行为时，你有一个清晰的线索可遵循，所以所有的异常处理程序都是非常有用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2149834|删除捕获是愚蠢的，因为在许多情况下，需要“处理”一些异常才能使程序正确工作(尽管您可能不同意如何处理它们，并且这种方法可能存在风险，但原始作者以这种方式编写代码是有原因的。如果他没有添加注释来解释他的原因，那么不要认为你比他更了解，特别是在“全局搜索和替换”的方式下)。|2149835|然而，似乎没有人指出最明显和最快实现的起点:转到“调试->异常”并为“公共语言运行时异常”部分启用"Break+when+exception+is++Runtime+“。这将导致调试器为抛出的每个异常而中断(在调用程序的catch块来处理它之前)，因此您将能够在调试器下测试应用程序，并确定当您尝试重复给定的bug时，哪些catch块抑制了哪些异常，然后您可以从中进行判断调用，以确定该特定catch块是否对所讨论的bug有任何影响。|offset|length|style|BOLD|2149836|entityMap^0|0|0|22|9|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Obviously logging all suppressed exceptions is the first place to start - blanket suppression is useful from time to time when you need to ensure that your code gracefully degrades under all circumstances (i.e. where you don't wish to be caught out by an exception type that you failed to anticipate), but can hide an unanticipated problem that needs more handling than simply being ignored, so it is imperative that all exception handlers should at a minimum report that an exception has been suppressed, so you have a clear trail of clues to follow if an unexpected behaviour emerges.

Removing the catches is foolish, as there will be many cases where some exceptions need to be "handled" for the program to work correctly (although you may disagree with how they are handled, and there may be risks associated with this approach, the original author had a reason for writing the code this way. Ig he has not added a comment explaining his reason, then don't assume you know better than he did, especially not in a "global search and replace" manner).

However, nobody seems to have pointed out the most obvious, and quickest to implement, starting point: Go to "Debug -> Exceptions" and enable "Break when exception is thrown" for the "Common Language Runtime Exceptions" section. This will cause the debugger to break for every exception that is thrown (before the program's catch block is called to handle it), so you will be able to test the application under the debugger and determine which catch blocks are suppressing which exceptions when you try to repeat a given bug, from which you can then make a judgement call as to whether or not that particular catch block has any influence on the bug in question.

blocks|key|2149845|text|按如下所示更改catch块：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2149846|catch+(Exception+ex)
{
++++Logger.Log(String.Format(
++++++++System.Globalization.CultureInfo.InvariantCulture,
++++++++"An+exception+is+being+eaten+and+not+handled.+"%2B
++++++++"This+may+be+hiding+critical+errors.\n"%2B
++++++++"Exception:+{0}",
++++++++ex));
}|code-block|syntax|javascript|2149847|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Change the catch blocks as follows:

<pre><code>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));
}
</code></pre>

<pre><code>catch(Exception ex)
{

}
</code></pre>

What's the best way to proceed? 

Rip them all out and let it crash?
Add logging code? Message boxes?
This is in C#.

Asked to fix bugs in a program, you find over 100 instances of

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

catch(Exception ex){}最好的方法是什么？把它们都拔出来然后让它崩溃？添加日志记录代码？消息框？这是在C#中。

问当被要求修复程序中的错误时，您会发现超过100个实例
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问当被要求修复程序中的错误时，您会发现超过100个实例EN