J2EE错误处理-应用程序和用户

Question

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

我们在代码中有基本的异常处理检查(需要工作)，但根据我的经验，向用户显示通用消息无助于加快故障排除过程。

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

1. 代码有一个错误
2. 错误被处理
3. 用户显示了一个具有特定错误代码的非技术性错误消息。
4. 非技术支持团队可以使用这个错误代码来查看区域(页面，部分，.)在发生这种情况的应用程序中，以及用户可能正在做的事情中(在客户支持参考指南中由开发团队预先填充的信息)。
5. 技术支持小组可以将代码直接用于类/JSP等，以及触发该类的代码行使用一个日志模块，其中大多数(并非所有) Tomcat stdout错误都由用户会话记录.对于用户将收到的错误代码，如果日志ID也存在，我们也可以包括它，这样技术团队也可以查看它。

基本上，我感兴趣的是减少支持性分析--解释--研究周期，让每个部门获取他们指尖上的信息，从而使他们在各自的工作中更快地开始工作：

1. 客户支持可以对此错误代码提供一个固定的解释，或者有用户可以遵循的其他步骤。
2. 技术团队可以开始对代码行进行故障诊断，或者用户正在做什么触发了这一行代码。

至关重要的是，每个错误代码触发了每个部门所需的下一步步骤，实际上减少了问题的研究阶段并进入了解决方案阶段。

我不确定以上是否是个好主意。对于这样的需求，任何建议都将被赞赏为一个良好的“设计模式”。或者这是否是一条很好的路线。

提前谢谢。

服务提供商

Answer 1

听起来，您需要花一些认真的时间来解决一些代码分类的支持问题。我的经验是，您几乎总是可以创建导致支持问题的50%+的“前10位列表”。删除前10个之后，重新检查调用日志。数据是必需的。

一个致力于解决支持问题并将其从公园中剔除的项目应该能够相当快地减少代码问题。在此之后，您将面临人力/可用性问题，这些问题必须通过培训、经验或通常是一些较长期的工作流/可用性重构来处理。

如果您正在陷入错误，您认为您需要开发一个错误代码/条件列表，这听起来您的产品需要另外6个月的稳定。您可能没有开发操作系统，对于99%的项目来说，开发一本IBMesque黑书错误代码并不是要模仿的模型。

Answer 2

使用log4j将所有错误和异常记录到通过电子邮件发送信息的记录器上。不要担心用户消息传递，他们所需要知道的只是一个错误，并且它已经被记录下来了。