为了有效地处理错误，必须了解可能发生的错误类型。让我们首先对您可能遇到的错误进行分类。
可能会发生各种类型的错误。然而，这些错误通常可以分为两类：
让我们将讨论过的错误分为这些类别。
从具有明确状态代码的服务器 API 收到的错误可以被视为预期错误，因为它们可以提前预测和解决。
例如未授权访问（401）或禁止访问（403）等错误，可以根据情况进行适当处理。为每个状态代码定义更详细的错误代码以管理响应错误的应用程序逻辑也很常见。这些被称为预期错误。
另一方面，500 范围内的服务器错误被归类为 意外错误，因为它们是不可预测的。服务器因任何原因无法响应的情况随时可能发生。另外，由于用户的网络环境或浏览器环境而可能出现的错误很难预测，因此被归类为意外错误。
错误还可以根据与用户的交互进行分类，而不仅仅是环境。对错误进行分类的一种方法是考虑用户是否可以对错误采取措施。以下是此分类的标准：
例如，身份验证或授权错误就属于此类。未登录的用户可能会遇到 401 状态错误。在这种情况下，您可以提供登录屏幕或显示一条消息，指示需要登录。
如果用户没有访问特定屏幕的权限，您可以引导他们向管理员请求访问权限。
没有一个产品开发者会欢迎用户放弃。为遇到错误的用户提供指导以帮助他们克服这种情况至关重要。例如，为临时网络错误提供刷新按钮，或者在访问不存在的页面时提供返回上一屏幕的按钮。
但是，在某些情况下，通知用户错误情况根本没有帮助。例如，如果代码包含无法在低规格设备或浏览器上运行的组件，则用户无法对其执行任何操作。 （也许是一条建议使用不同浏览器的消息？）
两种情况，1 和 2，都涉及提供消息。不同之处在于，案例 1 包含一些提示用户采取步骤的操作或指导。
遇到的错误是否是用户可以自行解决的？
那么，我们应该如何处理发生的错误呢？当发生错误时应用程序应该向用户提供什么样的界面？让我们根据不同类型的错误特点来探讨一下如何处理它们。
一个典型的例子是网络错误。这些可能随时发生，具体取决于用户的网络环境。最简单的解决方案是通知用户这是一个“临时错误”并提供重试之前操作的指导。
对于这些错误，确保整个应用程序不会受到不利影响至关重要。例如，如果一个应用程序在一个屏幕上调用 10 个 API，则失败的一个 API 不应在整个应用程序中触发错误消息，并且需要重试所有调用。
相反，只专注于恢复失败的区域。
这些错误很难预测并且没有直接的解决方案。在开发过程中应该尽量减少此类错误，并且应该有一个在发生错误时进行处理的计划。由于用户无法自行解决这些错误，因此可能有必要提供一种简单的方式来联系客户支持。
开发人员无法控制的错误应使用 Sentry 等工具进行监控。需要修复这些错误以防止用户遇到它们。此外，确保有一种机制可以让用户在遇到此类错误时返回到应用程序。
这些是已知错误，用户没有可用的解决方案。如果用户无法自行解决这些问题，则表明错过了错误处理的机会。如果用户故意执行异常操作，则可能是存在安全漏洞的迹象。
当有恶意利用该应用程序时，就会出现这些错误。它们通常源于安全漏洞，应该在开发过程中加以预防。解决 CORS 和 XSS 等基本安全问题并与安全团队协作构建安全的应用程序至关重要。
这些错误通常是开发人员已经意识到的业务逻辑的一部分：
在这些情况下，请在应用程序内提供适当的指导或创建单独的页面来指导用户。
用户应该清楚地了解遇到错误消息后下一步该做什么。这有助于减少错误频率并防止用户放弃。因此，除了错误消息之外，还必须包含号召性用语。
例如，如果存在字段验证错误，请关注发生错误的字段。如果用户导航到不存在的页面，请提供一个返回上一屏幕的按钮。
我们探索了错误处理。让我们利用各种工具和技术来有效地管理错误，例如错误监控工具和React的ErrorBoundary，它可以捕获有限范围内的错误。
