2014-07-02 4 views
0

Предположим, что мы получили удаленный EJB, который обеспечивает асинхронный метод с исключениемКак избежать поймать блок исключений на @Asynchronous метода EJB

@Stateless 
public class MyBean { 
    ... 

     @Asynchronous 
     public Future<Void> doSomething() 
     throws MyException 
     { 
      //implementation 
     } 

    ... 
} 

теперь на стороне клиента:

try { 
     Future<Void> result = myBean.doSomething() 
} 
catch(MyException e) 
{ 
     //Useless required catch block? 
} 

Я знаю, что исключение может быть получено из объекта Future при его возврате.

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

ответ

0

Действительно, если вы выбрали свое собственное исключение, вы решили, что вызывающий код должен иметь дело с ним, и вы делаете это, поймав его как с любым синхронным методом. И если вы говорите, блок catch бесполезен, тогда возникает вопрос: почему вы вообще исключаете исключение?

Чтобы избежать устранения исключения в клиентском коде, вы можете вместо этого вернуть объект, содержащий результат вызова, который может быть ошибкой, которая произошла. Вам все равно нужно справиться с этой ситуацией, но вам не понадобится блок try-catch. См., Например, this post.

Дополнительная информация: Java EE Tutorial.

+0

Да, я имел в виду будущее, заменил его в коде. Но исключение по вызову не будет выбрано, но должно быть уловлено, блок действительно раздражает. – SeeM

+0

@ СиМ: Хорошо, я понимаю - я изменил свой ответ. –

0

Еще одно решение - сделать MyException для расширения RunTimeException следующим образом. Не уверен, что это возможно для вас. Обратите внимание на annotaiton с rollback = false (предположим, что у вас есть проверенное исключение, если rollback не установлен в true). Таким образом, вам не нужно упоминать об этом в предложении throws или поймать его. В аннотации убедитесь, что она не будет завершена в EJBException.

@ApplicationException(rollback = false) 
public class MyExcepton extends RuntimeException { 

... 
} 
Смежные вопросы