EJB 3.0 Obsługa wyjątków

Question

cytat ze specyfikacji EJB:

Jeśli metoda fasola napotka wyjątek systemu lub błędu, należy prostu propagują błąd z metody fasoli do pojemnika (tj metoda bean nie musi wychwytywać wyjątku).

Ale nie rozumiem tego. Czy to oznacza, że ​​nie powinienem przechwytywać wszystkich typów wyjątków (np. Próbuję złapać klasę Exception) i ponownie je zgłosić jako wyjątek mojej aplikacji?

Przykładem dla większej jasności:

public void beanMethod throws MyApplicationException { 
    try { 
    // do something 
    } catch (Exception e) { 
    throw new MyApplicationException(e); // Should I do it like this? 
    } 
} 

A może to nie dla programistów EJB, ale tylko dla programistów EJB reference-wdrożeniowych (deweloperzy zbiornika): W tym ostatnim przypadku, w konsekwencji, pojemnik musi nie propaguje wyjątków systemu do mojej metody biznesowej, a mój blok catch(Exception e) nigdy nie przechwytuje żadnego wyjątku systemowego?

Answer 1

Istnieje rodzaj wyjątkami:

• wyjątki systemowe (. RuntimeExceptions np NullPointerException)
• wyjątki biznesowe (własny wyjątek, rozciąga wyjątku, ale nie RuntimeException np NotEnoughMoneyOnYourAccountException.)
• Błędy (np. OutOfMemoryError)

Zwykle powinieneś wychwycić wyjątki biznesowe. Ale oczywiście możesz rzucić to na stronę klienta, jeśli chcesz sobie z tym poradzić. Domyślnie kontener EJB nie będzie wycofać transakcję jeśli rzucisz BusinessException, ale można to zmienić poprzez opisywanie Twój Wyjątek następujący sposób:

@ApplicationException(rollback = true) 
public class NotEnoughMoneyOnYourAccountException extends Exception { 

Jeśli program generuje RuntimeException, zostanie on wysłany do klient jest opakowany jako wyjątek RemoteException, a transakcja zostanie wycofana. Są to mniej wyjątki niż biznesowe wyjątki, dlatego zwykle nie łapiemy ich po stronie EJB.

Błędy są najmniej wyjątkowe, mogą nawet wyłączyć maszynę JVM, zwykle ich nie łapiemy, ponieważ zazwyczaj nie możemy obsłużyć ich w programie.

Answer 2

Nie wiem, skąd wziąłeś tę wskazówkę i jaki jest kontekst, ale wydaje się oznaczać, że sama metoda fasoli nie powinna w ogóle obsługiwać wyjątków, po prostu wyrzuć cokolwiek otrzyma. To zachowanie jest zwykle najlepiej realizowane przez dodanie wyjątków, które ciało może rzucić w zależności od czynników środowiskowych/losowych, takich jak zmienne dane wejściowe w klauzuli throws gdzie MyApplicationException jest teraz.

Wyjątki powodowane bezpośrednio przez błędy kodu w metodzie (nie w wywołaniach metod) zwykle nie są wymagane, aby można je było prawidłowo obsługiwać, ponieważ powinny zostać usunięte podczas testowania i debugowania.