Aller au menu - Aller au contenu

Icône Gestion des erreurs et page d'accueil

Par Avatar cysboy
Mise à jour : 18/02/2011
Difficulté : Facile Facile Creative Commons BY-NC-SA
10 160 visites depuis 7 jours, dont 122 sur ce chapitre classé 25/786
Je vous l'avais dit dans le précédent chapitre : la plate-forme JEE offre une gestion des erreurs qui vous permet, entre autres, d'appliquer des filtres.
En plus de ça, vous pouvez aussi afficher des pages spécifiques selon que l'erreur provienne d'un problème de page non trouvée, d'une exception Java…

Ce chapitre ne sera pas très dur et sera relativement court, mais il n'en sera pas moins intéressant. :)
Retour en haut
Sommaire du chapitre :
Icône du chapitre
Chapitre précédent Sommaire Chapitre suivant
Retour en haut

Erreurs HTTP

Vous vous en souvenez peut-être, je vous avais fait un état des lieux des messages HTTP dans la partie I. Allez, je suis sympa, les voici de nouveau :

  • Code 1XX, réponse provisoire :
    • 100 : OK pour continuer,
    • 101 : le serveur a changé de protocole ;
  • Code 2XX, réussite :
    • 200 : (ok) la requête a été traitée avec succès,
    • 201 : (object created, reason = new URI) document créé,
    • 202 : (async completion (TBS)) requête achevée de manière asynchrone,
    • 203 : (partial completion) requête achevée de manière incomplète,
    • 204 : (no info to return) aucune information à retourner,
    • 205 : (request completed, but clear form) requête terminée mais formulaire vide,
    • 206 : (partial GET furfilled) requête GET incomplète ;
  • Code 3XX, redirection :
    • 300 : (server couldn't decide what to return) code de retour impossible à déterminer par le serveur,
    • 301 : (object permanently moved) document déplacé définitivement,
    • 302 : (object temporarily moved) document déplacé temporairement,
    • 303 : (redirection with new access method) redirection avec nouvelle méthode d'accès,
    • 304 : (if-modified-since was not modified) le champ 'if-modified-since' n'était pas modifié,
    • 305 : (redirection to proxy, location header specifies proxy to use) redirection vers un proxy spécifié par l'entête,
    • 307 : (HTTP/1.1: keep same verb) HTTP/1.1 ;
  • Code 4XX, erreur de requête client :
    • 400 : (invalid syntax) erreur de syntaxe,
    • 401 : (access denied) pas d'autorisation d'accès au document,
    • 402 : (payment required) accès au document payant,
    • 403 : (forbidden) la ressource demandée existe mais vous n'avez pas le droit d'y accéder,
    • 404 : (page not found) la ressource demandée n'existe pas sur le serveur,
    • 405 : (method is not allowed) méthode de requête du formulaire non autorisée,
    • 406 : (no response acceptable to client found) requête non acceptée par le serveur,
    • 407 : (proxy authentication required) autorisation du proxy nécessaire,
    • 408 : (server timed out waiting for request) temps d'accès à la page demandée expiré,
    • 409 : (user should resubmit with more info) l'utilisateur doit soumettre à nouveau avec plus d'infos,
    • 410 : (the resource is no longer available) cette ressource n'est plus disponible,
    • 411 : (the server refused to accept request w/o a length) le server a refusé la requête car elle n'a pas de longueur,
    • 412 : (precondition given in request failed) la précondition donnée dans la requête a échoué,
    • 413 : (request entity was too large) l'entité de la requête était trop grande,
    • 414 : (request URI too long) l'URI de la requête était trop longue,
    • 415 : (unsupported media type) type de média non géré ;
  • Code 5XX, erreur du serveur :
    • 500 : (internal server error) erreur interne du serveur,
    • 501 : (required not supported) requête faite au serveur non supportée,,
    • 502 : (error response received from gateway) mauvaise passerelle d'accès,
    • 503 : (temporarily overloaded) service non disponible,
    • 504 : (timed out waiting for gateway) temps d'accès à la passerelle expiré,
    • 505 : (HTTP version not supported) version HTTP non gérée.


Rappelez-vous, les erreurs correspondent aux codes commençant par 4 (erreur du client) ou 5 (erreur du serveur) et ce sont celles-ci que nous allons capturer et gérer.

En fait, depuis quelques chapitres, nous utilisons toujours le même code d'exemple et, sauf si vous tapez l'URL entière à chaque fois pour accéder à la page de connexion, vous devez voir systématiquement s'afficher une belle erreur 404. Ceci est normal car, lorsque vous saisissez une requête ne pointant pas vers une page spécifique, par défaut, le serveur regarde si une page s'appellant index est présente dans l'arborescence dans laquelle vous vous trouvez. Dans le cas contraire, le serveur interprète la demande du client comme une erreur d'URL provenant du client et renvoie donc l'erreur 404.

Si nous reprenons l'application utilisée dans le chapitre précédent, lorsque vous cliquez sur le lien permettant d'y accéder dans Tomcat Manager, vous devriez obtenir ceci :

Image utilisateur


Vous l'aurez sans doute deviné, c'est dans le fichier web.xml que nous allons gérer ces cas de figure.
Ce que nous allons faire, c'est afficher une page que nous aurons codée au préalable. Appelons-la 404.jsp et mettons-la à la racine de notre application.

Voici son code source (j'y ai ajouté un peu de fantaisie... ^^ ) :

Code : JSP
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<%@ page import="java.awt.Color" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>ERREUR 404 : page non trouvée</title>
</head>
<body>

<%
	Color tab[] = {
					new Color(Color.lightGray.getRGB()),
					Color.gray,
					Color.darkGray,
					Color.black,
					Color.red,
					Color.pink,
					Color.orange,
					Color.yellow,
					Color.green,
					Color.magenta,
					Color.cyan,
					Color.blue
				}; 
	String titre = "ERREUR 404";
	String message = "La page demandée n'est pas disponible ! ";
	char tabTitre[] = titre.toCharArray();
	
	out.print("<h1>");
	
	for(int i = 0, j = 0; i < tabTitre.length; i++, j++){
		if(j == tab.length) j = 0;
		out.print("<span style=\"color:rgb(" + tab[j].getRed() + ", " + tab[j].getGreen() + ", " + tab[j].getBlue() + ")\">" + tabTitre[i] + "</span>");
	}
	
	out.print("</h1>");
	
	char tabMessage[] = message.toCharArray();
	
	out.print("<p>");
	
	for(int i = 0, j = 0; i < tabMessage.length; i++, j++){
		if(j == tab.length) j = 0;
		out.print("<span style=\"color:rgb(" + tab[j].getRed() + ", " + tab[j].getGreen() + ", " + tab[j].getBlue() + ")\">" + tabMessage[i] + "</span>");
	}
	
	out.print("</p>");

%>

</body>
</html>


Nous allons bientôt voir à quoi ressemble cette page, mais il nous reste maintenant à configurer notre application afin que celle-ci affiche notre page à la place de celle fournie par Tomcat. Ceci se fait, dans le fichier web.xml, grâce au bloc suivant :

Code : XML
1
2
3
4
<error-page>
  <error-code>code de l'erreur à intercepter</error-code>
  <location>URL de la page à afficher lorsque cette erreur survient</location>
</error-page>


Dans le bloc <error-code></error-code>, nous n'avons qu'à insérer le code à intercepter, dans notre cas : 404.
Ensuite, dans le bloc <location></location>, pour que Tomcat sache, en toute circonstance, trouver la page à afficher, il faut mettre le chemin absolu menant à celle-ci ; donc, le chemin DOIT commencer par un "/" !

Ce qui nous donne :

Code : XML
1
2
3
4
<error-page>
   <error-code>404</error-code>
   <location>/404.jsp</location>
</error-page>


Redémarrez Tomcat, retournez dans Tomcat Manager et cliquez de nouveau sur le lien menant à l'erreur 404. Vous devriez maintenant obtenir ceci :

Image utilisateur


Voilà : c'est tout simple. Maintenant, si vous souhaitez intercepter une autre erreur, il vous suffit de réitérer ce que nous venons de faire et le tour est joué. :)

Je vous propose à présent de voir comment gérer les erreurs pendant les traitements.
Retour en haut

Gérer les exceptions

Vu que vous pourriez avoir besoin d'afficher une page spécifique lorsqu'une exception Java est levée, nous allons aborder ce point tout de suite. Le principe est le même que pour les erreurs HTTP sauf que, cette fois, nous allons dire à Tomcat d'afficher une page spécifique lorsque une exception d'un certain type est levée.

Prenons comme exemple une bête servlet qui, malheureusement, fait une division par zéro.
Voici ce que pourrait donner l'exécution de celle-ci (je ne vous la fournis pas, vous êtes capables de la faire tout seul maintenant ^^ ) :



Image utilisateur


Vous pouvez voir l'exception qui est levée : ArithmeticException.

Comme précédemment, nous allons créer une page spécifique afin de l'afficher en cas d'exception.
La voici :

Code : JSP
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>ArithmeticException</title>
</head>
<body>

<p>Une exception de type : <strong>java.lang.ArithleticException</strong> a été détectée !</p>

</body>
</html>


Il ne nous reste plus qu'à insérer le bloc de configuration dans le fichier web.xml. Voici celui que j'ai utilisé :

Code : XML
1
2
3
4
<error-page>
  <exception-type>java.lang.ArithmeticException</exception-type>
  <location>/arithmetic.jsp</location>
</error-page>


La seule différence avec le bloc vu précédemment, c'est ce qu'on déclare : une classe Java au lieu d'une erreur HTTP. Par contre, n'omettez pas le nom de package, sinon ça ne fonctionnera pas... Une fois ceci fait, voilà ce que j'ai obtenu en lieu et place de l'erreur renvoyée par Tomcat :

Image utilisateur


Alors ? Je ne vous avais pas dit que c'était vraiment enfantin ? :)

Petite question : dans ton exemple, le serveur retourne une erreur HTTP 500. Si nous avions aussi configuré une page pour cette erreur en plus de la page pour l'exception, que se passerait-il ?


Je vous invite à essayer : vous aurez votre réponse ; vous verrez que la page mappée sur une exception est prioritaire sur la page d'erreur HTTP. Une dernière chose, vous ne pouvez pas cumuler les types dans le bloc XML, ainsi ceci :

Code : XML
1
2
3
4
5
<error-page>
  <error-code>404</error-code>
  <exception-type>java.lang.ArithmeticException</exception-type>
  <location>/arithmetic.jsp</location>
</error-page>


... n'est pas permis ! Alors, attention.
Bon : nous avons vu comment gérer des erreurs ; maintenant, je vais vous montrer comment paramétrer la page par défaut lorsqu'on arrive sur l'application.
Retour en haut

Configurer vos pages par défaut

Un petit rappel est de mise avant de parler de ceci...
Vous devez savoir que lorsque vous naviguez sur un site, quand vous arrivez à l'accueil ou, plus globalement, lorsque l'URL renseignée ne pointe pas vers un fichier mais vers un dossier, vous avez tout de même, en règle générale, une page qui s'affiche.

Prenons un exemple concret. Lorsque vous arrivez sur le Site du Zéro, l'URL dans votre navigateur est la suivante : http://www.siteduzero.com/.
Normalement, vous avez tout de même une page devant les yeux. :) Pourtant, aucun fichier n'est spécifié...

Comment c'est possible ?

En fait, c'est comme si vous aviez tapé http://www.siteduzero.com/index.html.
Sur votre site préféré, la page d'accueil par défaut est index.html sauf que, vu que c'est celle par défaut, il n'est pas nécessaire de la spécifier : le serveur le fait de façon implicite. Ce dernier ne voit pas de nom de fichier, il regarde donc s'il y a une page du nom de la page par défaut ; si oui, il l'affiche et dans le cas contraire : erreur !

Ce mode de fonctionnement s'applique à tous les dossiers d'un site. Regardez ce schéma :

Image utilisateur


Sur ce schéma, vous pouvez voir que, sur notre site, seul le dossier à la racine de notre application et le dossier "dossier2" ont une page par défaut ; appelons-la, pour l'exemple, default.jsp. De ce fait, voici les adresses qui vous afficheront une page :


Par contre, si on saisit l'adresse http://www.monsite.com/dossier1/, deux cas de figure sont possibles :
  • le serveur autorise la navigation dans les dossiers ; dans ce cas, vous verrez une liste de fichiers et/ou de dossiers, comme ceci :

    Image utilisateur


  • le serveur n'autorise pas la navigation dans les dossiers et là, vous aurez une erreur vous indiquant que vous n'avez pas le droit d'accès, comme sur cette image :

    Image utilisateur




On comprend, mais comment fait le conteneur pour savoir qu'une page est définie comme étant une page par défaut ?

C'est simple, c'est configuré dans le fichier <répertoire d'installation de Tomcat>/conf/web.xml et, tout au bout de ce fichier vous trouverez ceci :

Code : XML
1
2
3
4
5
<welcome-file-list>
  <welcome-file>index.html</welcome-file>
  <welcome-file>index.htm</welcome-file>
  <welcome-file>index.jsp</welcome-file>
</welcome-file-list>


Maintenant, vous savez quel nom doivent avoir les pages pour qu'elles soient considérées comme pages par défaut.
La bonne nouvelle, c'est que vous pouvez redéfinir ceci dans le fichier web.xml de votre application, et, ainsi, définir vos propres noms de fichiers comme page par défaut.

Dans les exemples précédents, nous n'accédions pas directement à la page connexion.jsp. Maintenant, c'est le moment d'ajouter une petite définition dans notre fichier web.xml :

Code : XML
1
2
3
<welcome-file-list>
  <welcome-file>connexion.jsp</welcome-file>
</welcome-file-list>


Une fois ces lignes ajoutées, je vous invite à redémarrer Tomcat et retourner dans Tomcat Manager afin d'aller dans notre exemple... Magie ! :magicien:
Vous accédez directement à la page de connexion, sans spécifier explicitement son nom : connexion.jsp fait maintenant partie des noms de fichiers que Tomcat prend comme fichier par défaut.

Deux précisions avant de terminer ce chapitre. Vous aurez remarqué que les noms de fichiers, dans le descripteur de déploiement, ne commencent pas par un "/" ; ensuite, lorsque vous redéfinissez les pages par défaut, la configuration au niveau de Tomcat est supplantée : n'oubliez pas de mettre les fichiers standard (index.html, index.jsp et index.htm) si vous souhaitez les utiliser.

Une petite question : comment se passeraient les choses s'il y avait, dans un même dossier, deux fichiers portant des noms de fichiers par défaut ?

C'est très simple : Tomcat prendrait le premier nom de fichier et le considérerait comme prioritaire. Par exemple, si nous avons ceci dans notre descripteur de déploiement :

Code : XML
1
2
3
4
<welcome-file-list>  		
   <welcome-file>index.jsp</welcome-file>
   <welcome-file>connexion.jsp</welcome-file>  		
</welcome-file-list>


et si les deux fichiers se trouvaient dans le même répertoire que vous appelez, c'est index.jsp qui sera affiché. Essayez et vous verrez (n'hésitez pas à inverser l'ordre des fichiers dans le descripteur de déploiement...).

Voilà : vous venez d'apprendre pas mal de choses, je vous propose donc un QCM. ^^
Retour en haut

Q.C.M.

Comment pouvez-vous dire à Tomcat d'afficher une page spécifique lorsque survient une erreur HTTP ou une exception Java ?
Ce bloc de code est-il correct ?

Code : XML
1
2
3
4
<error-page>
   <error-code>404</error-code>
   <location>404.jsp</location>
</error-page>

Ce bloc est-il correct ?

Code : XML
1
2
3
4
<error-page>
  <exception-type>IOException</exception-type>
  <location>/exception.jsp</location>
</error-page>
Lorsque l'URL saisie dans le navigateur pointe vers un dossier, une page par défaut est affichée systématiquement, qu'elle soit ou non dans ce dossier.
Dans votre fichier web.xml, cette instruction :

Code : XML
1
2
3
<welcome-file-list>
  <welcome-file>connexion.jsp</welcome-file>
</welcome-file-list>


rajoute le fichier connexion.jsp à la liste des fichiers par défaut.

Statistiques de réponses au QCM

Retour en haut
Alors ? Je vous avais dit qu'il ne serait pas méchant, ce chapitre. ^^
Avant de passer à la partie III, je crois qu'il est maintenant temps de mettre tout ça en pratique.
Chapitre précédent Sommaire Chapitre suivant
Retour en haut

Partager

Retour en haut
3 commentaires pour "Gestion des erreurs et page d'accueil"
Note moyenne : 3.17 / 4 (294 votes)
Pseudo Commentaire
Hors ligne Don_Diego # Posté le 18/04/2011 à 21:50:07

merci cys!

la suite pleeeeeeeeeeeeeeeeeeeas!
Hors ligne biggi # Posté le 28/07/2011 à 16:35:06

D'abord merci pour ce tuto!

Enfin il y a une erreur au niveau du qcm.

Question
Lorsque l'URL saisie dans le navigateur pointe vers un dossier, une page par défaut est affichée systématiquement, qu'elle soit ou non dans ce dossier.
Mauvaise réponse
Faux.
La bonne réponse était
Vrai.

Explications
Faux.
Il faut que la page par défaut soit présente dans le dossier concerné, sinon, soit nous avons un message d'erreur, soit le contenu du dossier est listé.
Hors ligne gilloull # Posté le 11/12/2011 à 15:51:47
Avatar

Études : ENSEA

 Merci pour le tutoriel, il me sert beaucoup actuellement.

Je viens quand même de galérer 2h sur un point très très bête mais qui n'était pas précisé et qui concerne la capture des exceptions par le web.xml :

Il faut bien penser à ce que la méthode qui génère le "throw new XyzException()" soit capable elle même de la faire suivre à travers un "throws XyzException" car sinon Eclipse impose un "try/catch" qui de fait ne propage pas l'erreur au serveur.

Si la signature de la méthode ne peut pas être modifiée (cela vient de m'arriver pour "Filter.doFilter", il faut penser à faire hériter son exception d'un type d'exception que cette méthode peut faire suivre (dans mon cas ServletException ou IOException).

Au moins maintenant je saurai :)
^^ Comme les oeufs, les temps sont durs ^^
 

Voir tous les commentaires