应用错误处理

我们不能依靠用户来报告生产中的所有错误。用户通常会在遇到错误时离开网站，并且很可能不会向我们报告该问题。当他们报告问题时，我们将获得哪些信息？我们需要重现该问题吗？他们在哪个网址上？但是，可以捕获，记录，确定优先级和调查这些信息。

我们选择的方法

我们通过Sentry（https://sentry.io）将传统日志记录与解决异常集成在一起。 Sentry主要用于可操作的错误或崩溃（crashes）。我们应该主动做的事情。 Sentry将通过崩溃报告捕获我们需要的其他信息，并提供解决错误的界面。 Sentry不能替代传统的日志记录。 Sentry也不替代APM（应用程序性能监视）。如果我们要使用Rollbar或Sentry的任何其他替代方法，则将应用相同的原则。

For instance (pseudo code):伪代码

try {
  pseudoJson = this->getPseudo();

  return response(Response.HTTP_SUCCESS, pseudoJson);
} catch (PseudoException exception) {
  Sentry.captureException(exception);

  Log.error(
    'pseudo: Unable to pseudo '. NEW_LINE . exception
  );

  return response(Response.HTTP_BAD_REQUEST, ['Friendly user message :)']); 
}

在该示例中，我们同时使用了传统的日志记录和Sentry。最后，给出了用户友好的响应。这只是一个示例，在所有情况下，我们都应考虑记录和不记录的内容。例如，在没有实际异常或错误的情况下记录警告和信息可能是适当的。在这种情况下，可能不需要使用Sentry登录。请注意，异常也可以在全局级别捕获，并不总是需要try catch。

Log.info('Restarting pseudo');
Log.warning('Pseudo deprecation');

我们应该使用不同的日志记录级别（例如错误，警告，信息等）。日志记录级别使我们能够区分正在记录的内容。

什么时候该catch，什么时候不catch？

仅当您具有有意义的处理方式时才捕获异常。如果仅记录异常并将其进一步抛出堆栈，则不要捕获异常。它没有意义，代码混乱。如果您期望代码的特定部分失败，并且对此有备用，或者打算以特定方式抛出它，请务必捕获异常。全局异常处理将涵盖其他所有内容。

有关错误处理的更多信息

在应用程序中设置 Sentry

必须设置Sentry以全局捕获应用程序异常。对于Nuxt，可以通过以下模块来实现：https://github.com/nuxt-community/sentry-module。而对于节点api，我们需要将Sentry添加到正确的位置以捕获全局错误，例如：

process.on('uncaughtException', function(error) {
  // capture sentry exception
});

process.on('unhandledRejections', function(reason, promise) {
 // capture in sentry
});

对于我们的api服务，请考虑设置私有npm软件包，以向我们提供与vendor无关的实现。因此，我们实现了vidaXL错误处理，并且无论Sentry（raven），滚动条或其他任何背后的方法都调用相同的方法。因此，如果我们确实切换到其他vendor，则会在一个地方而不是在所有API上进行更新。

其他要考虑的事情

生产代码中不应使用console.log。 -（我们可以基于此使用linting和fail管道）。
我们应该记录该应用程序的发行版本，以便我们可以与代码的特定版本相关。可以在Sentry配置中设置“发布 release”。

Sentry警报

Sentry提供的集成中包括添加松弛集成的功能。这样的集成可以用来显示新的错误，然后由团队来承担。单独的备用通道可用于监视不同的应用程序和不同的环境。

错误调查

在监视监视通道时，团队可以组织自己，但是应该经常检查这些通道。一旦出现新的错误，应最多调查一个小时。在此时间内，可以确定错误的优先级。如果需要立即解决问题，则团队必须优先解决此问题。如果不是很紧急，那么错误可能仍然是可以立即解决的快速修复，或者可以创建后续凭单并与产品所有者进行跟进，后者可以将其计划为冲刺。

Previous开发规范 Next框架使用

Last updated 5 years ago

Was this helpful?