【问题标题】:Proper EJB Exception handling - ClassNotFoundException from client正确的 EJB 异常处理 - 来自客户端的 ClassNotFoundException
【发布时间】:2009-09-10 02:08:24
【问题描述】:

我有一些使用 Hibernate 将数据持久保存到数据库的 EJB。我有一个与这些 EJB 对话的厚 Swing 客户端。客户端对数据库一无所知(没有驱动程序 jar)。

在一个事务期间,可能会引发 Hibernate ConstraintViolationException。我捕获所有异常并将它们包装在 EJBException 中,如下所示:

catch(HibernateException e) {
    e.printStackTrace();
    throw new EJBException(e);
}

我遇到的问题是,当客户端的 JBoss Invoker 解组异常时,会抛出 ClassNotFoundException(对于 PSQLException),因为客户端在类路径中没有 sql 驱动程序 jar。

我将此应用程序更改为始终将捕获的异常传递给 ejbexception 构造函数,这样我们就可以获得堆栈跟踪历史记录。现在我找到了为什么最初的开发人员没有这样做。

此时我看到了两个选项 - 要么将 postgres 驱动程序 jar 包含在客户端中,要么删除将捕获的异常传递给 EJBException 构造函数。我很好奇是否有人有任何其他建议以及其他人如何处理其 EJB 中的异常?

【问题讨论】:

    标签: java ejb


    【解决方案1】:

    我的看法是,客户、最终用户不需要知道问题的技术细节。因此,在各个层边界上,将技术异常转换为一般的“自然发生 XYZ 错误”是非常合理的。

    我见过的一个方案是让服务器在检测到异常时分配一个唯一的错误号。然后它将诊断信息写入其日志,包括该数字。报告给客户端的消息只包含数字。然后,支持台可以通过该特定错误号关联用户的问题报告。

    【讨论】:

    • +1 表示“客户不需要知道技术细节”。不过,我认为完全没有必要使用唯一错误号方法。所有客户端需要知道的是“发生了服务器错误”。服务器日志应提供故障排除所需的所有信息。
    • 当你有很多用户并且他们的错误报告并不总是及时或准确,并且你有一个非平凡的 n 层架构,我相信这些错误数字确实有效并且是远非不必要。实施的工作量是微不足道的。
    • 我的错。我的意思不是“不必要”,而是“毫无意义” :-) 我们已经尝试过这种方法,发现实际错误数在大约 0.5% 的情况下会返回给我们;其余的被报告为“某种错误”或“弹出窗口”。但也许你的用户比我的好 - 我只能羡慕你:-)
    • @djna - 我也倾向于“客户不需要知道技术细节”的想法。但是,我能找到的所有“最佳实践”信息都建议将捕获的异常传递给抛出的 EJBException(例如,Enterprise Java Beans 3.0 书 - Burke,Monson-Haefel)。但仔细想想,这没有任何意义。服务器可能会使用客户端永远不需要知道的各种 API,并将这些 API 的异常传递给客户端似乎是一种不好的做法。
    • 我认为大多数 EJB 客户端最终都是 servlet,所以它们都在服务器端,因此类路径问题更容易处理。这使得标准建议更加合理。我 100% 确定您的分析适合您正在做的胖客户端案例。没有“最佳实践”之类的东西,只有在某些情况下有用并有其后果的实践;您的情况揭示了传递捕获的异常的一些后果。
    猜你喜欢
    • 1970-01-01
    • 2015-08-18
    • 1970-01-01
    • 1970-01-01
    • 2019-07-27
    • 2015-04-26
    • 1970-01-01
    • 2015-06-02
    • 1970-01-01
    相关资源
    最近更新 更多