2011-09-14 13 views
13

Czy istnieje standardowy sposób przechwytywania nieprzechwyconych wyjątków, które występują wewnątrz kontenera serwletu Java, takiego jak tomcat lub Jetty? Prowadzimy wiele serwletów, które pochodzą z bibliotek, więc nie możemy łatwo umieścić naszego kodu "try/catch". Byłoby również miło, aby w jak najszerszym zakresie przechwytywać i rejestrować wszystkie nieprzechwycone wyjątki w naszej aplikacji internetowej (która działa w Jetty) do naszego narzędzia do śledzenia błędów za pośrednictwem udostępnionego interfejsu API.Jak pobrać niezatłoczone wyjątki w aplikacji WWW serwletu Java

Nie muszę logować wyjątków, tylko czy przekierowanie jest przyczyną problemu z niestandardową stroną błędu. Robimy wszystko za pomocą GWT-RPC, aby użytkownik nigdy nie widział strony błędu.

Odpowiedz

11

W web.xml (deskryptor wdrażania) można użyć elementu <error-page> do określenia stron błędów według typów wyjątków lub HTTP response status code. Np

<error-page> 
    <error-code>404</error-code> 
    <location>/error/404.html</location> 
</error-page> 
<error-page> 
    <exception-type>com.example.PebkacException</exception-type> 
    <location>/error/UserError.html</location> 
</error-page> 

Dla o NetBeans zorientowane opisu mosey do ponad Configuring Web Applications: Mapping Errors to Error Screens (The Java EE 6 Tutorial) (lub zobaczyć the Java EE 5 Tutorial's version).

+3

Warto podkreślić, że błąd obsługi kodu serwletu można pobrać wyjątek od 'request' obiektu w' javax.servlet.error.exception' atrybutu. Np .: 'request.getAttribute (" javax.servlet.error.exception ")' – nilskp

3

Nie 100% pewien, czy to będzie działać z kontenerem serwletów, albo jak daleko powyżej tej rozmowy musiałyby iść, ale można nazwać statycznegosetDefaultUncaughtExceptionHandler sposób na Thread ustawić obsługi, która będzie obsługiwać wszystkie przechwycone wyjątki .

13

Myślę, że niestandardowy filtr rzeczywiście działa najlepiej.

@Override 
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { 
    try { 
     chain.doFilter(request, response); 
    } catch (Throwable e) { 
     doCustomErrorLogging(e); 
     if (e instanceof IOException) { 
      throw (IOException) e; 
     } else if (e instanceof ServletException) { 
      throw (ServletException) e; 
     } else if (e instanceof RuntimeException) { 
      throw (RuntimeException) e; 
     } else { 
      //This should never be hit 
      throw new RuntimeException("Unexpected Exception", e); 
     } 
    } 
} 
+2

Post o korzystaniu z 'strony błędów 'jest właściwą drogą do wykonania tego w środowisku serwletu. – nilskp

+1

W rzeczywistości powyższe rozwiązanie javax.servlet.Filter działa bardzo dobrze w środowisku serwletów. I podoba mi się to, że nie musimy edytować pliku web.xml. – David

+0

ten przykład spowodowałby efekt uboczny wychwytywania błędów (podklasa nie-Wyjątek, z której można wykonywać i konwertować je do wyjątków). Ponieważ błędy są wewnętrznymi problemami związanymi z samą maszyną JVM (takimi jak OutOfMemoryError lub ThreadDeath). Ponieważ sama JVM musi radzić sobie z błędami, jej złym sposobem jest łapanie nalotów i przekształcanie ich w wyjątek, który nie będzie właściwie obsługiwany przez maszynę JVM. (http://stackoverflow.com/questions/6083248/is-it-a-bad-practice-to-catch-throwable) –

Powiązane problemy