0

我有一个关于在 J2EE 应用程序中处理错误的问题。我们当前的应用程序被许多用户使用，因此我们得到了很多支持票。这些票证中的大多数与用户相关，但 5-10% 是系统相关的异常、未处理的错误等。

我们在代码中有基本的异常处理检查（需要工作），但根据我的经验，向用户显示一般消息并不能帮助加快故障排除过程。

我正在寻找的是关于良好错误处理设计模式的建议，以便让我们考虑一个场景：

  1. 代码有错误
  2. 错误已处理
  3. 向用户显示带有特定错误代码的非技术错误消息。
  4. 非技术支持团队可以使用此错误代码来查看应用程序中发生这种情况的区域（页面、部分、..）以及用户可能一直在做什么（开发团队在客户支持参考指南中预先填充的信息）。
  5. 技术支持团队可以在类/JSP 等和触发该异常的代码行中使用代码归零。
  6. 我们使用一个日志模块，其中大多数（不是全部）Tomcat 标准输出错误都由用户会话记录……到用户将收到的错误代码中，如果它也存在，我们可以包含日志 ID，以便技术团队可以查看也。

基本上，我感兴趣的是减少支持分析-解释-研究周期，让每个部门都能触手可及地访问信息，这可以让他们更快地开始各自的工作：

  1. 客户支持可以对此错误代码给出预设解释，或者提供用户可以遵循的替代步骤。
  2. 技术团队可以开始对代码行或触发该行的用户正在做什么进行故障排除。

本质上，每个错误代码都会触发每个部门所需的后续步骤，实际上减少了问题的研究阶段并进入解决阶段。

我不确定以上是否是个好主意。对于这种需要的良好“设计模式”，任何建议都将不胜感激。或者如果它甚至是一个很好的途径。

提前致谢。

SP

4

2 回答 2

2

听起来您需要花一些时间来解决一些代码分类的支持问题。我的经验是，您几乎总是可以创建导致 50% 以上的支持问题的项目的“前 10 名列表”。完成前 10 个后，重新检查通话记录。数据势在必行。

一个致力于解决支持问题并将它们淘汰出局的程序应该能够相当快地筛选出代码问题。之后，您将面临必须通过培训、经验或通常一些长期工作流程/可用性重构来处理的人/可用性问题。

如果您陷入了您认为需要制定错误代码/条件列表的错误中，那么听起来您的产品还需要再稳定 6 个月。您可能没有开发操作系统，并且对于 99% 的开发 IBMesque 错误代码黑皮书的项目来说，这不是要效仿的模型。

于 2008-11-07T23:36:08.070 回答
0

使用 log4j 将所有错误和异常记录到通过电子邮件发送给您信息的记录器。不用担心用户消息；他们只需要知道有一个错误并且它已被记录。

于 2008-11-08T03:59:22.330 回答