Gestion des exceptions dans Jsp

Question

Comment allez-vous gérer l'exception sans envoyer à la page d'erreur? Comment allez-vous définir un détail de message à l'objet d'exception? (Ne pas utiliser les JSTL Tags)

Merci, Ravi

Answer 1

Ne pas utiliser les tags JSTL

J'allais dire la c:catch, mais que vous ne voulez pas utiliser JSTL, il arrête ici.

Encore alors, ça aurait été une mauvaise idée. Normalement, vous ne voulez pas utiliser JSP pour la logique métier. Utilisez simplement (indirectement) une servlet pour cela. Avec Servlets, vous pouvez contrôler, pré-traiter et/ou post-traiter les demandes et transmettre la requête au fichier JSP qui affiche les données en utilisant EL et contrôle dynamiquement le flux de la page en utilisant taglibs comme <jsp:xxx> et JSTL.

Voici un exemple de base repose sur l'idée « d'utilisateur de connexion »:

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { 
    String username = request.getParameter("username"); 
    String password = request.getParameter("password"); 

    if (username == null || username.isEmpty() || password == null || password.isEmpty()) { 
     request.setAttribute("error", "Please enter both username and password."); 
    } else { 
     User user = userDAO.find(username, password); 
     if (user == null) { 
      request.setAttribute("error", "Unknown login, please try again."); 
     } else { 
      request.getSession().setAttribute("user", user); 
      request.setAttribute("succes", "Login succesful!"); 
     } 
    } 

    request.getRequestDispatcher("login.jsp").forward(request, response); 
} 

puis l'exemple JSP de base:

<form action="login" method="post"> 
    Username: <input type="text" name="username" value="${param.username}"><br> 
    Password: <input type="password" name="password" value="${param.password}"><br> 
    Login: <input type="submit" value="Login"><br> 
    <span class="error">${error}</span> 
    <span class="succes">${succes}</span> 
</form> 

Vous pouvez aller plus loin en utilisant par exemple un Map<String, String> pour la messages afin que vous puissiez attacher un message d'erreur à chaque champ de saisie. Vous pouvez aller plus loin en utilisant un framework MVC qui prend tout ce travail de vos mains, mais c'est une autre histoire;)

Answer 2

Je pense que la meilleure réponse est que vous ne le faites pas.

Il est considéré comme un bon design avec la technologie jsp pour gérer tout ce qui peut provoquer des exceptions avant de démarrer la phase de rendu. Cela signifie que vous devriez normalement essayer de faire des choses qui peuvent provoquer des exceptions dans les méthodes "execute" dans votre framework web avant d'arriver à la page jsp. Si vous avez besoin d'attraper quelque chose, faites-le là.

Answer 3

Presque chaque application web est développée en utilisant MVC de sorte que 90% de l'utilisation du code java dans le sol est réduit Les 10% restants peuvent atteindre avec des tags JSTl de tags standard ou personnalisés et EL.

Si pas suivi sa mauvaise idée pour gérer l'exception. Depuis jsp est destiné uniquement à la logique de présentation.

Se reporter à JSP Exception Handling

Answer 4

La plupart des réponses sont juste dire que la plupart des choses qui peuvent déclencher des exceptions se produisent dans le contrôleur dans une configuration MVC et devrait y être traitées.

Mais toujours - des exceptions dans JSP se produisent. Si vous dites juste, ils ne devraient pas arriver, cela n'aide pas du tout. JSP La gestion des exceptions est difficile car le tampon JSP est rincé de temps en temps (la taille par défaut est de 8 Ko, mais le vidage se produit également sur chaque jsp: include). Si le tampon est vidé, la réponse est validée. "commit" signifie que la réponse est partiellement écrite au client. Donc les en-têtes http et peuvent être le corps http est déjà envoyé.

Si la réponse n'est pas validée, le conteneur de servlet peut forward à la page d'erreur configurée.

Si la réponse est déjà validée, le conteneur de servlet ne peut pas gérer facilement l'exception. Tomcat tente toujours de le faire, si vous avez configuré un <error-page> dans votre fichier web.xml. Au moins tomcat essaie d'inclure à la place de forward la page d'erreur. C'est généralement mauvais et la sortie est complètement garbage. Si une exception se produit à nouveau ou tomcat est incapable de le manipuler pourrait montrer une trace de la pile (dépend de la façon dont vous avez configuré ErrorReportValve)

La seule façon de gérer les exceptions dans JSP est complètement un filtre à mon avis:

public class BufferingFilter extends AbstractHttpFilter 
{ 
    private static final String FIX_HTML = "<html><body>An error occured and even the error handling failed. This should not happen. We are going to fix it as soon as posssible.</body></html>"; 

    @Override 
    protected void doHttpFilter (HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException 
    { 
     BufferingResponse contentBufferingResponse = new BufferingResponse(response); 
     try 
     { 
      chain.doFilter(request, contentBufferingResponse); 
      OutputStream out = response.getOutputStream(); 
      out.write(contentBufferingResponse.getData()); 
      out.close(); 
     } 
     catch (Exception e) 
     { 
      if (request.getDispatcherType().equals(DispatcherType.ERROR)) 
      { 
       response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); 
       response.getWriter().append(FIX_HTML); 
       response.flushBuffer(); 
      } 
      else 
      { 
       throw e; 
      } 
     } 
    } 
} 

De cette façon, vous tamponnez toutes vos réponses jsp. Ainsi, vous serez sûr que la réponse d'origine n'est pas validée au moment où une exception se produit. Vous pouvez comme avec throw e jeter l'exception à la bulle. Tomcat redirige ensuite vers votre page d'erreur. Mais si vous êtes déjà dans le répartiteur d'erreur, vous affichez une page d'erreur par vous-même.

De cette façon, vous ne verrez jamais une trace de pile avec votre moteur tomcat.

Un avantage intéressant est une bonne compression gzip avec votre connecteur http si vous l'avez configuré avec compression = on car le filtre peut compresser le tampon complet en une fois. Sinon, tous les morceaux de données ne sont pas compressés car ils sont trop petits.

Il se peut que l'utilisation de la mémoire soit plus importante. Mais pour nous j'ai regardé l'utilisation de la mémoire sur un côté de la circulation élevée et il n'a pas augmenté de façon surprenante.