EJB3.1 Системные исключения против javax.EJB-компонента.EJBException

IndoKnight, что идеально завернуть вам дал как Exception семантика в рамках Java EE.. работа.

вот две единственные строки "bean provider", то есть вы и я, должны знать об исключениях в Java EE:

ваш bean полностью свободен для восстановления от любого типа исключения или ошибки, как вы считаете нужным, в отношении других ограничений, под которыми может находиться bean. Если вы оправились от исключения, то поздравляю-проблем нет anymore =)

соответствующим ограничением может быть, например, то, что" корпоративные компоненты, использующие демаркацию транзакций, управляемых контейнером, не должны использовать методы управления транзакциями, которые мешают границам демаркации транзакций контейнера", чтобы процитировать Java EE 7 учебник 48-2 страницы (вы хотите программно установить откат управляемой транзакции контейнера, используйте метод ejbcontext.setRollbackOnly()).

Вам также не рекомендуется, как и в любом типе приложения Java, обрабатывать Throwable или Error брошенный с очень низкого уровня. RuntimeException теоретически считается в этой категории, поскольку он так лихо сигнализирует об "ошибке разработчика", которая похожа на" совершенно неожиданную", но мы все знаем, что это не так.

в основном, неожиданное исключение (исключения времени выполнения + другое дерьмо, которое мы предполагаем, происходит от кого-то другого) предполагается, что ваш код не может быть обработан и должен обрабатываться сервером. Сервер должен обрабатывать исключение" unhandleable" (посмотреть спецификация EJB 3.2, стр. 204), напечатав что-то об этом в журнале (я перейду к деталям немного позже!).

более конкретно..

вы спросили (И вот во что я верю или не верны):

все исключения приложений описанное выше должно быть брошено непосредственно EJB клиенту?

да. и транзакция (если она активна) не должна откатываться, если вы явно не указываете, что она должна использовать атрибут отката ApplicationException. Исключение Java-кода-это очень естественная вещь. Java EE не имеет намерения разрушать эту модель программирования. Так что вперед, бросьте проверенные исключения, как вам нравится, заставляя клиентов пытаться поймать те или отметьте исключения среды выполнения как исключения приложения и бросьте их тоже. Счастливого броска!

если системные исключения обернуты внутри javax.EJB-компонента.EJBException перед бросая клиенту, затем javax.EJB-компонента.EJBException считаются Системное Исключение?

да, но не по той причине, которую вы предоставляете. Чтобы быть ясным, нет типа SystemException. Это просто причудливая формулировка для описания таких исключений, которые большинство бобов там не могло произойти, и скорее всего, они происходят из контейнера EJB. Ваш код определенно не должен вызывать EJBException. Это, вероятно, только помешало бы уму сервера. Также вы не можете аннотировать исключение как @ApplicationException так как вы не владеете кодом, он предоставляется API Java EE. Вы можете расширить EJBException, но не имеет смысла маскировать ваш код как часть кодовой базы сервера. Наиболее главное, с EJBException расширяет RuntimeException, я думаю, что безопасно классифицировать EJBException как "исключение системного уровня".

Берегись Дьявола

некоторые пульт ДУ клиенты получат исключения remoteexception вместо исключения EJBException.

перехватчики что вы, возможно, даже не знаете в огромном проекте предприятия, может проглотить исключения, брошенные из вашего метода выполнение активной транзакции commit хотя у вас никогда не было планов позволить ему это сделать.

держу пари, вы думаете, что a подавленные исключением всегда извлекается с помощью Throwable.getCause(). Обратите внимание, что спецификация EJB 3.2 не говорит, что контейнер должен или должен щадить ссылку на подавленную причину. Фактически, единственное, что должен сделать контейнер, это зарегистрировать исключение. Тогда, если Боба нет одноэлементный экземпляр bean должен быть отброшен и больше никогда не использоваться. Кроме того, если компонент является управляемым сообщением компонентом, только тогда требуется "обернуть"исходное исключение. Как "обернуть" исключение не указано. Супер портативный прохладный код, вероятно, следует взглянуть на подобное.getCause() метод и Throwable.getSuppressed () тоже. Не ожидайте, что в вашем коде обработки всегда будет найдено исходное исключение.

асинхронные методы (методы публичного сеанса bean аннотированы @асинхронные), который возвращает void, не может распространять исключение на своего клиента. Таким образом, они не должны объявлять или исключения приложений (посмотреть спецификация EJB 3.2 страница 82). Обратите внимание, что при вызове асинхронного метода сервер может не предоставить потоковые ресурсы для обслуживания вашего запроса, и если это так, он должен бросить.. EJBException (страница 48)!