Gestion des exceptions dans Struts 2
Il y a très peu de différences dans la gestion des exceptions entre les versions 1 et 2 de Struts. Ce document décrit les éléments à surveiller.
Arrière-plan
Flux d'exception :Le flux de base pour la gestion des exceptions dans la version 2 est le même que le flux de Struts 1, et fonctionne comme suit :
- Lorsqu'une exception est détectée par appel logique interne, l'exception sera encapsulée et gérée dans BaseAction. Dans la logique de gestion, une nouvelle unité d'exécution d'erreur sera créée et appelée, ce qui aidera ultérieurement à générer un chemin de transfert d'erreur.
- Pour le chemin d'erreur, la structure Struts 2 prendra le contrôle et dirigera la page vers un résultat d'erreur préconfiguré. Il peut s'agir d'une configuration d'emplacement locale ou globale.
- Après l'envoi d'une requête de rendu de page, un JSP de gestion des erreurs est exécuté, ce qui génère des résultats d'erreur que les navigateurs peuvent exploiter.
Par rapport à Struts 1, la seule différence réside dans la façon dont l'exception et les messages sont insérés dans la structure Struts par défaut.
Dans Struts 1, BaseAction place l'exception dans les attributs HttpServletRequest en appelant la méthode saveErrors() d'action. Si un client souhaite consommer ultérieurement les informations d'erreur d'une page JSP, il peut utiliser la balise <html:errors/> pour accéder aux informations d'exception.
Struts 2 utilise une nouvelle balise <s:actionerrors/> pour afficher les messages d'erreur dans la façade de la page.
Le contenu de la version 1 du JSP ressemblera à ceci :
<logic:messagesPresent message="false">
<html:errors/>
</logic:messagesPresent>
En revanche, le contenu de la version 2 ressemble à ce qui suit :
<s:if test="hasActionErrors()">
<div>
<s:actionerror/>
</div>
</s:if>