Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/java/324.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
EJB3.1系统异常与javax.ejb.EJBException_Java_Jakarta Ee_Exception_Java Ee 6_Ejb 3.1 - Fatal编程技术网

EJB3.1系统异常与javax.ejb.EJBException

EJB3.1系统异常与javax.ejb.EJBException,java,jakarta-ee,exception,java-ee-6,ejb-3.1,Java,Jakarta Ee,Exception,Java Ee 6,Ejb 3.1,在提出我的问题之前,先了解一下EJB3.1异常的背景知识- 申请例外包括 用户定义的已检查或未检查异常 @ApplicationException注释 所有已检查的异常 java.lang.Exception&它的子类Exception 除了java.rmi.RemoteException&它的子类异常 系统异常包括 java.rmi.RemoteException及其子类异常 所有未检查的异常 java.lang.RuntimeException及其子类异常 java.lang.Erro

在提出我的问题之前,先了解一下EJB3.1异常的背景知识-

申请例外包括

  • 用户定义的已检查或未检查异常 @ApplicationException注释

  • 所有已检查的异常

    java.lang.Exception&它的子类Exception
    除了java.rmi.RemoteException&它的子类异常

系统异常包括

  • java.rmi.RemoteException及其子类异常

  • 所有未检查的异常

    java.lang.RuntimeException及其子类异常
    java.lang.Error及其子类异常

下面是我在这篇文章中读到的一个声明

在EJB中,客户端不排除系统异常,当遇到此类异常时,这些异常不会按原样传递给客户端,而是封装在javax.EJB.EJBException中

我的问题-

  • 上面描述的所有应用程序异常都应该由EJB直接抛出到客户端吗
  • 如果系统异常在抛出到客户端之前被包装在javax.ejb.EJBException中,那么javax.ejb.EJBException是否被视为系统异常
  • 是的,或多或少他们就是这样工作的。有关EJB行为的更多详细信息,请查看以下博文:
  • 此外,从这一点:

    出现异常时,应引发应用程序异常 业务逻辑错误,与系统错误相反

    有一个重要的区别:应用程序异常不会 自动导致事务回滚。客户有一个 引发应用程序异常后进行恢复的机会

    将应用程序异常发送到客户端而不重新打包 作为EJBException。因此,您可以使用它们来报告验证 错误或业务逻辑问题,它们将到达客户端

  • javax.ejb.EJBException
    扩展了
    RuntimeException
    所以是的,它是一个系统异常

  • 与此相关的常见场景:如果应用程序代码中有未捕获的
    运行时异常
    ,它将回滚。这是非常有用的默认行为。

    indowknight,您对Java EE框架中的
    Exception
    语义做了多么完美的总结。。工作

    以下是“bean提供者”(即您和我)需要了解的Java EE中异常的两行代码:

    您的bean完全可以自由地从您认为合适的任何类型的异常或错误中恢复,这与bean可能受到的其他约束有关。如果您从异常中恢复,那么恭喜您-不再有问题了=)

    例如,一个相关的约束可能是“使用容器管理的事务划分的企业bean不得使用任何干扰容器事务划分边界的事务管理方法”引用第48-2页(要以编程方式设置容器管理事务的回滚,请使用)

    与任何类型的Java应用程序一样,您也不愿意处理从非常低的级别抛出的
    Throwable
    Error
    RuntimeException
    理论上属于这一类,因为它发出了一个“开发人员错误”的信号,就像“完全出乎意料”——但我们都知道它不是

    基本上,一个意外的异常(运行时异常+我们认为来自其他人的其他狗屎)被认为是不可由您的代码处理的,应该由服务器来处理。服务器需要通过在日志中打印一些关于它的信息来处理“不可处理”的异常(参见,第204页)(我稍后再谈细节!)

    更具体地说。。 你问(以下是我相信或坚持的观点):

    是否应该抛出上述所有应用程序异常 直接通过EJB到客户端

    是。和事务(如果事务处于活动状态)除非使用的rollback属性明确声明应该回滚,否则不会回滚。Java代码抛出异常是一件很自然的事情。Java EE无意破坏此编程模型。因此,继续,随意抛出选中的异常,强制客户端尝试捕获这些异常或标记运行时异常s作为应用程序异常,也抛出这些异常。愉快地抛出

    如果系统异常在之前包装在javax.ejb.EJBException中 抛出到客户端,那么javax.ejb.EJBException被认为是 系统异常

    是的,但不是因为您提供的原因。要清楚,没有称为SystemException的类型。它只是用花哨的措词来描述那些大多数bean都没有想到会发生的异常,它们很可能来自EJB容器。您的代码绝对不应该抛出EJBException。这样做可能只会阻碍服务器的思维。您也不能将异常注释为@ApplicationException,因为您不拥有代码,它是由Java EE API提供的。您可以扩展EJBException,但将代码伪装为服务器代码库的一部分没有任何意义。最重要的是,因为 EJBException扩展了RuntimeException,我认为将EJBException归类为“系统级异常”是安全的

    提防魔鬼 一些远程客户端将收到而不是EJBException

    拦截器在一个大型企业项目中,您可能根本不知道,它可能会吞下从方法中抛出的异常,使活动事务提交,即使您从未计划让他这样做

    我打赌您认为抑制的异常总是可以使用进行检索的。请注意