处理所有异常的正确时间

Question

到目前为止，我已经完成了一些项目，我注意到我所写的每一个项目都完全没有任何异常处理，最后我做了很多测试并处理它们。

是吗？我在测试时得到了数以千计的异常（我立即修复），如果我已经处理它，我就不会看到它的确切位置（当不使用断点或在任何地方显示它时......但它似乎并不实际）所以我通过检查任何异常来解决问题，然后最终我处理它们，因为任何可能已经转义的（当然）。

你呢？你们什么时候处理例外情况？

Answer 1

就个人而言，我总是定义一个适用于应用程序类型的全局未处理异常管理器，并将该日志和电子邮件例外发送给我的开发团队。在QA期间，我们将开始为具有可预测（和可恢复）问题的例程添加特定的异常管理。在每种情况下，我们都会添加防御性编程代码，以便根本不会发生异常。 （如果您在尝试可能失败的代码之前进行测试，则无需捕获异常。）

我的应用程序往往最终会出现大量防御性代码（应该从头开始构建）并且只有一些特定的异常处理。

Answer 2

我更喜欢测试驱动的开发。如果存在预期的错误情况，则进行测试。如果出现意外错误，请对其进行测试，然后进行修复。

Answer 3

我会说这是倒退（但很常见）。

您可能希望研究测试驱动开发，并测试第一个设计

提示：想一个行为，编写代码来测试它，将它添加到你的应用程序中。

Answer 4

我会肯定考虑在开发每个接口和模块时抛出的异常。

通过这种方式，您可以测试它们是否被可靠地抛出（当您期望时，而不是在您不期望时）。然后可以编写使用这些组件的组件以了解这些异常并处理（或不按需要）。

在我看来，你忽略了你正在开发的组件的一些功能。我几乎总是会测试正确的功能和特殊情况，尽可能多地覆盖尽可能多的场景。

Answer 5

这个问题的答案非常清楚“它取决于”。

您需要了解具体情况;是一个异常被抛出一个特定的代码片段，它可以恢复或处理导致异常被抛出的“异常”情况？在这种情况下，是的，抓住异常并在该级别处理它。

另一方面，你在谈论不可恢复的错误吗？那么肯定的是，在一个更全局的层面捕捉它们，或者可能根本不捕捉它们（也就是说，如果没有什么可以对异常做什么，你为什么要捕捉它？）

Answer 6

通常在哪里捕获异常的规则是：您可以在哪里有意义地处理它们。

Answer 7

有时它取决于技术或目标平台。我通常更喜欢处理所有异常的异常处理层。每个代码块都在try catch块中。

最重要的是，操作系统或程序或代码之外的任何其他实体都不应该捕获任何异常。

Answer 8

与从API返回错误代码相比，异常之处在于您不必检查代码中每个层的异常。您可以捕获特定的异常以确定特定的错误条件，并可能处理错误或重新抛出更合适的异常。您还必须在应用程序中捕获高级别的异常，以避免未处理的异常。

需要注意的一点是，异常的用户通常是开发人员而不是最终用户。后者通常不了解例外的技术细节。

Answer 9

我见过的最常见的事情是开发人员有意识地选择处理异常的级别，并允许它们被抛出。通常，它将处于工作线程或高级业务逻辑的级别。允许异常发生，并采用一种处理/记录它们并保护用户免受这些异常的一揽子方法。

时间是通常发生的事情和你做的事情之间的唯一区别。从一开始就在应用程序中规划它，并在高级别进行异常处理。

修复特定异常是通过您解决问题的方法来完成的。有时我使用的库将不必要地使用异常来传递信息，我将围绕对该库的所有调用添加专门的异常处理。通常我会在一个包装类中执行此操作，该类隐藏了我的应用程序其余部分的实现和异常处理。