我的测试没有发现bug，所以系统没有bug，对吧？不幸的是，无论进行多少测试，大型软件都太复杂了，不可能没有错误。您无法测试用户使用您的应用程序的所有不同方式。因此，了解应用程序中错误和异常之间的区别以及正确的处理方式非常重要，这样您才能采取主动的方法为您的开发团队和最终用户交付健康的应用程序。测试的局限性即使是最彻底的测试过程，你仍然只是在测试一个特定的情况，并在其中包含你自己的想法。想象一下突然有成千上万的用户以您意想不到的方式使用您的应用程序——他们几乎肯定会遇到您在测试时没有遇到的问题。如何正确处理应用程序中的错误简单地说，错误会导致错误和异常。错误和异常是具有不同含义的术语。主要问题应该是如何更好地处理这些错误和异常，以免它们产生负面后果。首先，让我们看一下一些定义以及为什么这些区别很重要。错误和异常——有什么区别？有些编程语言对错误和异常有自己的定义，但我想定义一下它们的区别。无法正常恢复/继续的编程错误，通常需要开发人员介入并修改代码来修复它。有时错误可以转化为异常，因此可以在代码中处理它们。错误可以通过简单的检查来避免，如果简单的检查还不够，还可以将错误转化为异常，让应用程序优雅地处理。异常利用特定于语言的语义并指示何时发生异常。可以捕获并抛出异常，以便代码可以在不进入错误状态的情况下恢复和处理这种情况。可以抛出和捕获异常，以便应用程序可以恢复或正常继续。还可以记录未处理的异常（即错误），以便开发人员可以查看它们以修复潜在的错误。Example#1UserError——用户输入了错误的数据，也不需要异常处理，但仍然会导致错误/不可恢复的状态。代码应该有简单的检查以防止这种情况发生。前端和后端验证都应该使用，对于这种情况，只抛出异常作为“最后的防御”。示例#2文件无法打开并抛出FileLoadException或FileNotFoundException。这是一种特殊情况，不应破坏应用程序。应用程序应该能够处理这种情况，因为发生这种情况的原因有很多，因此，您必须预料到这种情况。应该出错或会出错的地方……至少一次“所以……如果我捕获所有异常，我的代码就不会出错，对吧？”正如我前面提到的，并非所有错误都会导致异常。这个结论的主要问题是你不知道哪里出了问题。您的代码可能存在很多问题，捕获异常而不对它们做任何处理，您就会丢失信息。不要只是捕获每个异常并像什么都没发生一样继续。捕获块的目的是处理某些情况。什么都不做-抓住他们。如何编写应用程序以自我恢复抛出和捕获异常是允许应用程序自我恢复并防止其运行到错误状态的好方法。如果您知道可能会抛出哪种类型的异常，最好在catch块中明确显示它，因为每种不同类型的异常都意味着代码会因不同的原因而停止。具体说明异常类型，以便您可以向用户提供反馈并在您确切知道失败发生的原因后更优雅地处理其他情况。为什么指定要捕获的异常类型很重要？某些异常可能会损坏数据或以意想不到的方式运行，具体取决于您的程序如何继续运行。这将导致应用程序出错。如果您确切知道发生了哪个异常，那么您应该知道要遵循哪些步骤来恢复。或者，如果无法恢复，您应该知道如何优雅地处理这种情况。那么，它能恢复吗？在许多情况下，异常有足够的信息可以知道哪里出了问题，并且在catch块内，您有时可以从错误状态中恢复。这可以通过修复一些数据、重新获取数据，甚至要求用户重试来完成。您可以捕获异常，但有时应用程序仍然无法继续，因为它所依赖的数据已经以不可恢复的方式损坏，或者它希望数据采用不同的格式。示例数组出现OutOfRangeException？程序如何恢复？这是一个将错误变成异常的例子。您的应用程序希望数据以某种方式显示，但事实并非如此。虽然恢复并不总是可能的，但现在可以不进入错误状态并优雅地处理这种情况。如果记录在案，开发人员可以通过在访问数组之前添加一些简单检查或更改访问方式来解决此问题。如何处理未处理的异常有些异常是您意想不到的，通常表示您的代码中存在错误。您可以记录未被您的代码捕获的未处理异常，因为大多数语言都提供了这样做的方法。任何未处理的异常都表示错误。您的代码没有预料到这一点，因此无法恢复或优雅地处理这种情况。记录它们是个好主意，这样它们就可以被修复。这样，错误就不会经常抛出异常。如果它们真的发生了，你想了解它们，这样你就可以抓住它们并处理它们。错误日志错误日志可以帮助捕获这些错误。有一个地方可以查看这些日志错误/异常是调试和确定何时修复问题的优先级的关键。此外，您不想依赖屏幕截图和来自已经沮丧的用户的更多信息。错误日志记录还使您的团队能够在发生错误时主动联系受影响的用户。这是为了让他们知道您正在解决问题，这不仅会促进您的客户关系，而且您还会在其他用户遇到错误之前修复错误。示例代码中产生多个错误计费的错误通常比无法显示特定详细信息页面的错误更严重，即使详细信息页面错误发生得更频繁。最终，您希望您的应用程序遇到尽可能少的异常，但当它发生时，您希望了解它。只有1%的用户报告了错误，因此仍然存在大量错误。解决部分问题编写一些代码将异常和堆栈保存到文件中，或者通过电子邮件发送它以便在出现问题时得到通知可能是部分解决方案。示例用户遇到了数千个异常。100个用户也遇到了频率较低的错误。哪个更重要？在不知道错误细节的情况下，影响更多用户的错误更重要。使用异常的堆栈应该有助于找到错误可能出现的位置，并且您应该能够重新生成它或阅读代码以了解那里出了什么问题。有时这还不够，问题需要进一步调查。如果发生这种情况，请在记录异常之前向异常添加更多信息，包括允许您在本地重现错误的上下文特定详细信息（例如帐户ID或特定对象状态）。是时候修复错误了现在，您应该已经捕获了所有错误和异常，并记录了未处理的错误……现在怎么办？根据应用程序的大小，错误通知中的噪声可能是个问题。您可以使用电子邮件过滤/grep做一些聪明的事情，它将错误分组并将它们分成不同的文件夹/文件。这可能有所帮助，但只是噪音问题的部分解决方案。几年前我亲自这样做过，但很快意识到出于多种原因这只是部分解决方案。问题是，我仍然不知道哪些错误对用户影响最大。我专注于抛出的错误，而不是那些对应用程序/用户体验最有害的错误——正因为如此，我从来没有真正清楚地知道出了什么问题。我看不到发生了什么，但必须运行手动查询才能弄清楚，这很耗时。对于大型软件，总是会抛出错误和异常。正确处理错误将有助于将您定义为一个软件团队，并围绕异常和错误创建更好的流程。好的应用程序包含可以在可能的情况下从异常中恢复的代码。异常的处理和记录对软件的运行状态非常重要！欢迎关注我的公众号，如果你有喜欢的外文技术文章，可以通过公众号留言推荐给我。
