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

Question

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

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

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

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

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

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

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

我不确定上述内容是否是个好主意。对于这种需要，任何建议都会在一个好的“设计模式”上受到赞赏。或者，如果它甚至是一个很好的途径。

提前致谢。

SP

Answer 1

听起来你需要花一些时间来讨论支持问题以进行一些代码分类。我的经验是，您几乎总能创建一个“前10名”项目，这些项目会导致50％以上的支持问题。在敲掉前10个之后，重新检查通话记录。数据势在必行。

致力于解决支持问题并将其淘汰出局的计划应该能够很快地解决代码问题。在此之后，您将面临人力/可用性问题，这些问题必须通过培训，经验或通常一些较长期的工作流程/可用性重构来处理。

如果您遇到错误，您认为需要开发错误代码/条件列表，那么听起来您的产品需要另外6个月的稳定性。您可能不开发操作系统，并且99％的项目开发IBMesque错误代码黑皮书不是模拟的模型。

Answer 2

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