Pourquoi parler de la gestion des exceptions dans le projet J2EE? Peut-être que de nombreux débutants de Java veulent dire: "La manipulation des exceptions n'est-elle pas juste d'essayer ... Catch ... enfin? Tout le monde le sait!" L'auteur pense également de cette façon lorsqu'il apprend Java pour la première fois. Comment définir la classe d'exception correspondante dans un projet J2EE multicouche? Comment gérer les exceptions à chaque couche du projet? Quand l'exception est-elle lancée? Quand l'exception est-elle enregistrée? Comment enregistrer les exceptions? Quand dois-je convertir l'exception vérifiée en exception non contrôlée, et quand dois-je convertir l'exception non contrôlée en exception vérifiée? L'exception doit-elle être présentée à la page frontale? Comment concevoir un cadre d'exception? Ces questions seront discutées dans cet article.
1. Manipulation de l'exception Java
Dans les langages de programmation procédurale, nous pouvons déterminer si la méthode est exécutée normalement en renvoyant la valeur. Par exemple, dans un programme écrit en langue C, si la méthode est exécutée correctement, elle reviendra 1. Si l'erreur est exécutée, elle reviendra 0. Dans une application développée par VB ou Delphi, lorsqu'une erreur se produira, nous ferons une boîte de message à l'utilisateur.
Nous ne pouvons pas obtenir les détails d'erreur via la valeur de retour de la méthode. Cela peut être dû au fait que la méthode est écrite par différents programmeurs, lorsque le même type d'erreur se produit dans différentes méthodes, les résultats renvoyés et les informations d'erreur ne sont pas cohérents.
Par conséquent, la langue Java adopte un mécanisme de traitement des exceptions unifié.
Qu'est-ce qu'une exception? Des erreurs captivables et processeurs se produisant au moment de l'exécution.
Dans la langue java, l'exception est la classe parent de toutes les exceptions. Toute exception est étendue à la classe d'exception. L'exception équivaut à un type d'erreur. Si vous souhaitez définir un nouveau type d'erreur, étendez une nouvelle sous-classe d'exception. L'avantage de l'utilisation d'exceptions est qu'il peut localiser avec précision l'emplacement du code source qui provoque l'erreur du programme et d'obtenir des informations d'erreur détaillées.
La manipulation des exceptions Java est implémentée via cinq mots clés, essayez, capture, lance, lance enfin. La structure de traitement des exceptions spécifique est implémentée par l'essai… .catch…. Blocage finalement. Le Block Try stocke les instructions Java qui peuvent avoir des exceptions. La capture est utilisée pour attraper la survenue d'exceptions et gérer les exceptions. Le bloc final est utilisé pour effacer les ressources non liées au programme. Le bloc final est toujours exécuté si le code qui ne gère pas le retour du bloc d'essai.
Un code de traitement des exceptions typique
public String getPassword (String userId) lève dataaccessException {String sql = "SELECT MOTOK-MOTY FROM UserInfo Where Userid = '" + userId + "'" String Motword = NULL; Connection Con = NULL; instruction S = NULL; ResultSet RS = Null; Try {Con = getConnection (); // Get Data Connections S = Con.CreatEstationTation (); tandis que (Rs.Next ()) {mot de passe = Rs.GetString (1);} rs.close (); s.close ();} catch (sqlexception ex) {lancez la nouvelle données de données (ex);} enfin {try {if (con! = null) {con.close ();}} catch (sqException sqlex) {thory Échec! ", SQLEX);}} retour de mot de passe;} On peut voir que les avantages du mécanisme de gestion des exceptions de Java:
L'erreur est classée uniformément et implémentée en étendant la classe d'exception ou sa sous-classe. Cela évite que la même erreur puisse avoir des messages d'erreur différents dans différentes méthodes. Lorsque la même erreur se produit dans différentes méthodes, il vous suffit de lancer le même objet d'exception.
Obtenez des informations d'erreur plus détaillées. Grâce à des classes d'exception, des informations d'erreur peuvent être données à l'exception plus détaillée et plus utile à l'utilisateur. Facile pour les utilisateurs de suivre et de déboguer les programmes.
Séparez le résultat de retour correct du message d'erreur. Réduit la complexité du programme. L'appelant n'a pas besoin d'en savoir plus sur le résultat de retour.
Forcer l'appelant à gérer les exceptions pour améliorer la qualité du programme. Lorsqu'une déclaration de méthode doit lancer une exception, l'appelant doit utiliser le bloc d'essai .... Catch pour gérer l'exception. Bien sûr, l'appelant peut également permettre à l'exception de continuer à être jetée au niveau supérieur.
2. Exception vérifiée ou exception non contrôlée?
Les exceptions Java sont divisées en deux catégories: exception vérifiée et exception non contrôlée. Toutes les exceptions qui héritent de Java.lang.Exception appartiennent à des exceptions vérifiées. Toutes les exceptions qui héritent de Java.lang.runtimeException appartiennent à des exceptions incontrôlées.
Lorsqu'une méthode appelle une méthode qui peut lancer une exception vérifiée, l'exception doit être capturée et traitée ou remontée dans le bloc d'essai ... Catch.
Jetons un coup d'œil à la déclaration de la méthode CreateStatement () de l'interface de connexion.
Création publique CreateStatement () lève SQELLECTENCE; SQLEXception est une exception vérifiée. Lorsque la méthode de CreateStatement est appelée, Java oblige l'appelant à capturer la SQLEXception. public String getPassword (String userId) {try {... instruction s = con.createStatement (); ... catch (sqlexception sqlex) {...} ...} ou
public String getPassword (String userId) lève SQException {instruction s = con.creatEstatement ();} (Bien sûr, des ressources comme la connexion et la solution doivent être fermées à temps. Il s'agit simplement d'illustrer que l'exception vérifiée doit forcer l'appelant à attraper ou à continuer à lancer)
L'exception non contrôlée est également appelée exception d'exécution. Habituellement, la RuntimeException indique une exception que l'utilisateur ne peut pas récupérer, comme l'incapacité d'obtenir une connexion de base de données, l'incapacité d'ouvrir un fichier, etc. Bien que l'utilisateur puisse également attraper des exceptions non contrôlées comme la gestion des exceptions vérifiées. Mais si l'appelant n'attrape pas l'exception non contrôlée, le compilateur ne vous obligera pas à le faire.
Par exemple, un code qui convertit les caractères en valeurs entières est la suivante:
String str = "123"; int value = Integer.ParseInt (str);
La signature de la méthode Parseint est:
Public Statint ParseInt (String S) lève NumberFormatexception
Lorsque les paramètres passés ne peuvent pas être convertis en entier correspondant, une conception NumberFormatexception sera lancée. Étant donné que NumberFormatexception s'étend à RuntimeException, il s'agit d'une exception non contrôlée. Il n'y a donc pas besoin d'essayer ... Catch lors de l'appel de la méthode Parseint
Parce que Java ne force pas l'appelant à attraper ou à lancer l'exception non contrôlée. Les programmeurs aiment donc toujours lancer des exceptions incontrôlées. Ou lorsqu'une nouvelle classe d'exception est nécessaire, elle est toujours utilisée pour s'étendre à partir de RuntimeException. Lorsque vous appelez ces méthodes, s'il n'y a pas de bloc de capture correspondant, le compilateur vous permettra toujours de passer et vous n'avez pas besoin de comprendre quelle exception cette méthode lancera. Il semble que ce soit une bonne idée, mais cela est loin de la véritable intention de la manipulation des exceptions de Java. Et il est trompeur pour le programmeur qui appelle votre classe, car l'appelant n'a aucune idée dans les circonstances dont il a besoin pour gérer les exceptions. L'exception vérifiée peut clairement indiquer à l'appelant quelles exceptions doivent être gérées lors de l'appel de cette classe. Si l'appelant ne le traite pas, le compilateur invite et ne peut pas compiler et passer. Bien sûr, comment y faire face est à l'appelant de décider.
Java recommande donc aux gens d'utiliser des exceptions vérifiées dans leur code d'application. Tout comme nous avons mentionné dans la section précédente que l'avantage de l'utilisation d'exceptions est qu'il peut forcer l'appelant à gérer les exceptions qui seront générées. Les exceptions vérifiées sont utilisées comme standard dans des documents Java officiels tels que "Tutoriel Java".
L'utilisation d'exceptions vérifiées devrait signifier qu'il y a beaucoup d'essais ... des captures dans votre code. Après avoir écrit et manipulé de plus en plus d'essayer… des blocs de capture, de nombreuses personnes ont finalement commencé à se demander si des exceptions vérifiées devraient être utilisées comme standard.
Même Bruce Eckel, l'auteur du célèbre "Thinking in Java", a changé ses anciennes pensées. Bruce Eckel préconise même d'utiliser des exceptions non contrôlées comme utilisation standard. Et publier un article pour tester si l'exception vérifiée doit être supprimée de Java. Bruce Eckel: "Lorsque une petite quantité de code, les exceptions vérifiées sont sans aucun doute un concept très élégant et aident à éviter de nombreuses erreurs potentielles. Mais l'expérience montre que le résultat est exactement le contraire pour une grande quantité de code."
Pour des discussions détaillées sur les exceptions vérifiées et les exceptions non contrôlées, veuillez vous référer à
Tutorial Java http://java.sun.com/docs/books/tutorial/essivential/exceptions/runtime.html
L'utilisation d'exceptions vérifiées peut causer de nombreux problèmes.
L'exception vérifiée provoque trop d'essayer ... Code de capture
Il peut y avoir de nombreuses exceptions vérifiées qui ne peuvent pas être gérées raisonnablement par les développeurs, tels que SQLEXception. Mais les développeurs doivent essayer ... Catch. Lorsque les développeurs ne peuvent pas gérer correctement une exception vérifiée, ils impriment généralement simplement l'exception ou ne font rien. Surtout pour les novices, trop d'exceptions vérifiées le font se sentir à perte.
essayez {… instruction s = con.createStatement ();… catch (sqlexception sqlex) {sqlex.printStackTrace ();} ou
essayez {... instruction s = con.createStatement (); ... catch (sqlexception sqlex) {// ne rien faire} L'exception vérifiée provoque de nombreuses générations de code difficiles à comprendre
Lorsque les développeurs doivent prendre une exception vérifiée qu'ils ne peuvent pas gérer correctement, ils sont généralement reconditionnés dans une nouvelle exception, puis jetés. Cela n'apporte aucun avantage au programme. Au lieu de cela, cela rend le code difficile à comprendre plus tard.
Tout comme nous utilisons le code JDBC, il y a beaucoup d'essais… Catch. Le code vraiment utile est inclus dans Try… Catch. Rendant difficile de comprendre cette méthode
L'exception vérifiée fait que l'exception est constamment encapsulée dans une autre exception de classe, puis jeté
public void methoda () lève exceptiona {… ..throw new exceptiona ();} public void methodb () lève exceptionB {try {methoda ();…} catch (exceptiona ex) {throw new exceptionB (ex);}} public void methodc () lance sauf exception {try {méthodeb ();…} catch (exceptionb ex) {throw Nous voyons que l'exception est encapsulée et remontée la couche par couche.
L'exception vérifiée provoque la corruption de la méthode d'interface
Une méthode sur une interface a été utilisée par plusieurs classes. Lorsqu'une exception vérifiée supplémentaire est ajoutée à cette méthode, tous les codes appelant cette méthode doivent être modifiés.
On peut voir que les problèmes ci-dessus sont obligés de capter et de traiter car l'appelant ne peut pas gérer correctement l'exception vérifiée, et sont obligés de s'encourager puis de remédier. Ceci est très gênant et n'apporte aucun avantage. Dans ce cas, des exceptions non contrôlées sont généralement utilisées.
L'exception vérifiée n'est pas tout. L'exception vérifiée est beaucoup plus facile à utiliser que la valeur de retour d'erreur de la programmation traditionnelle. Il est beaucoup mieux de veiller à ce que les exceptions soient traitées correctement via le compilateur que de juger par la valeur de retour.
Si une exception est mortelle, elle est irréalisable. Ou l'appelant va l'attraper sans aucun avantage, utilisez l'exception non contrôlée.
Si une exception peut être récupérée et peut être gérée correctement par l'appelant, utilisez l'exception vérifiée.
Lorsque vous utilisez une exception non cochée, l'exception non coché que la méthode peut lancer doit être décrite en détail dans la déclaration de la méthode. L'appelant décide de prendre l'exception non contrôlée
Quand utiliser des exceptions vérifiées et quand utiliser des exceptions non contrôlées? Il n'y a pas de norme absolue. Mais je peux donner quelques suggestions
Lorsque tous les appelants doivent gérer cette exception, l'appelant peut être autorisé à réessayer l'opération; ou l'exception est équivalente à la deuxième valeur de retour de la méthode. Utilisez l'exception vérifiée.
Cette exception ne peut être gérée que par quelques appelants plus avancés, et les appelants ordinaires ne peuvent pas le gérer correctement. Utilisez une exception non contrôlée. Les appelants qui ont la possibilité de traiter peuvent effectuer un traitement avancé, mais généralement les appelants ne le gèrent pas du tout.
Cette exception est une erreur très grave, telle que les erreurs de connexion de la base de données, l'échec du fichier à ouvrir, etc. ou ces exceptions sont liées à l'environnement externe. Il n'est pas possible de résoudre le problème de la réessayer. Utilisez une exception non contrôlée. Parce qu'une fois cette exception se produit, l'appelant ne peut pas le gérer du tout.
S'il n'est pas sûr, utilisez une exception non contrôlée. Et décrire en détail l'exception qui peut être jetée pour permettre à l'appelant de décider de le gérer.
3. Concevoir une nouvelle classe d'exception
Lors de la conception d'une nouvelle classe d'exception, vérifiez d'abord si cette classe d'exception est vraiment nécessaire. D'une manière générale, essayez de ne pas concevoir de nouvelles classes d'exception, mais essayez d'utiliser des classes d'exception qui existent déjà en Java.
comme
IllégalArgumentException, non étayée
Qu'il s'agisse de la nouvelle exception, d'une exception châquée ou d'une exception non contrôlée. Nous devons tous considérer le problème de nidification des exceptions.
public void methoda () lève exceptiona {… ..throw new exceptiona ();} Méthode Methoda La déclaration lance Exceptiona.
Public Void methodb () lève l'exceptionB
La déclaration de méthodeB lancera l'exceptionB. Lorsque la méthode est appelée dans la méthode MethodB, exceptiona ne peut pas être traitée, donc exceptiona devrait continuer à vomir. Une façon consiste à faire en sorte que la déclaration MethodB lance exceptiona. Mais cela a changé la signature de la méthode de MethodB. Une fois modifiée, toutes les méthodes qui appellent la méthodeb doivent être modifiées.
Une autre façon consiste à encapsuler Exceptiona dans ExceptionB, puis à le lancer. Si nous ne résurons pas exceptiona dans exceptionB, nous perdrons les informations d'exception racine, ce qui rend impossible de suivre la source originale de l'exception.
public void methethb () lève exceptionB {try {méthoda (); ...} catch (exceptiona ex) {throw new exceptionB (ex);}} Comme dans le code ci-dessus, ExceptionB niche une exception. Nous appellerons exceptiona "a causé une exception" pour le moment, car exceptiona provoque une exceptionB. Cela empêchera les informations d'exception de perdre.
Ainsi, lorsque nous définissons une nouvelle classe d'exception, nous devons fournir un tel constructeur qui peut contenir des exceptions imbriquées. Et il y a un membre privé pour sauver cette "cause à cause".
classe publique ExceptionB étend une exception {Cause logable privée; exception publiqueB (String msg, throwable ex) {super (msg); this.cause = ex;} public exceptionB (String msg) {super (msg);} public exceptionB (Throwable ex) {this.cause = ex;}} Bien sûr, lorsque nous appelons la méthode PrintstackTrace, nous devons imprimer toutes les informations "exceptionnelles" en même temps. Nous devons donc remplacer la méthode PrintstackTrace pour afficher toutes les traces de pile d'exception. Comprend des traces de pile d'exceptions imbriquées.
public void printstackTrace (printStrean ps) {if (cause == null) {super.printStackTrace (ps);} else {ps.println (this); cause.printStackTrace (ps);}} Une prise en charge complète du code source de classe d'exception vérifiée imbriquée est la suivante. Appelons cela NestException ici pour le moment
Public NetedException étend une exception {la cause logable privée; public NestException (String msg) {super (msg);} public NestException (String msg, Thrownable ex) {super (msg); this.cause = ex;} public thrownable getcause () {return (this.cause == NULL? super.getMessage (); Throwable Cause = getCause (); if (cause! = null) {message = message + "; Exception imbriquée est" + cause;} return message;} public void printstackTrace (PrintStream ps) {if (getCause == null) {super.printStackTrace (ps);} else {ps.println (this); getCause (). printStackTrace (ps);}} public void printstackTrace (printwrite pw) {if (getCause () == null) {super.printStackTrace (pw);} else {pw.println (this); getCause (). printStackTrace (pw);}} public void printstackTrace () {printtackTrace (System.Error);}}En outre, vous devez concevoir une classe d'exception non contrôlée comme ci-dessus. Il a juste besoin de hériter de RuntimeException.
4. Comment enregistrer les exceptions
En tant que grand système d'applications, les fichiers journaux sont nécessaires pour enregistrer le fonctionnement du système pour faciliter le suivi et l'enregistrement du fonctionnement du système. Les exceptions qui se produisent dans le système doivent naturellement être enregistrées dans le système de journal.
public String getpassword (String userId) lève NosuchUserException {userInfo user = userdao.QueryUserById (userId); if (user == null) {Logger.info ("Les informations utilisateur ne peuvent pas être trouvées, userId =" + userrid); lancez new nosuchuseRexception ("les informations utilisateur ne peuvent pas être trouvées, userrid =" + userrid); user.getpassword ();}} public void SenSeuserPassword (String userId) lève une exception {userInfo user = null; try {user = getPassword (userId); //… ..ssendmail (); //} catch (nosuchuserexception ex) (Logger.error ("cette information utilisateur ne peut pas être trouvée:" + userrid + ex); Nous avons remarqué qu'une erreur avait été enregistrée deux fois. À l'origine de l'erreur, nous n'enregistrons qu'au niveau des informations. Dans la méthode SendrauserPassword, nous enregistrons également l'intégralité des informations d'exception.
L'auteur a vu de nombreux projets enregistrer des exceptions de cette manière, quel que soit le 3721, et l'exception complète ne sera enregistrée que lors de la rencontre d'une exception. Si une exception est encapsulée en continu et jetée plusieurs fois, elle sera enregistrée plusieurs fois. Alors, où l'exception doit être enregistrée?
L'exception doit être enregistrée à l'emplacement initial!
Si vous devez prendre une exception qui ne peut pas être gérée correctement, encapsulez-la simplement dans une autre exception et jetez-la. Il n'est pas nécessaire d'enregistrer à nouveau l'exception enregistrée.
Si une exception est faite, cette exception peut être manipulée. Aucune exception ne doit être enregistrée
Date publique getDate (String str) {date applatDate = null; SimpledateFormat format = new SimpledateFormat ("mm / dd / yyyy"); try {applications) Lorsqu'une exception non enregistrée ou une exception du système externe est capturée, les détails de l'exception doivent être enregistrés.
essayez {… string sql = ”select * from userInfo”; instruction s = con.createStatement ();… catch (sqlexception sqlex) {logger.error ("Erreur d'exécution sql" + sql + sqlex);} Où enregistrer des informations d'exception et comment enregistrer les informations d'exception peut être une question d'opinion. Certains systèmes permettent même des exceptions d'enregistrement d'enregistrement de classe d'exception. Lorsqu'un nouvel objet d'exception est généré, les informations d'exception sont automatiquement enregistrées.
classe publique BusinessException étend une exception {private void LogTrace () {StringBuffer Buffer = new StringBuffer (); Buffer.APPEND ("Business Error in Class:"); Buffer.APPEND (GetClassName ()); Buffer.APPEND (", Method:"); Buffer.APPEND (GetMethodName ()); "); buffer.append (this.getMessage ()); logger.error (buffer.toString ());} public BusinessException (String S) {super (s); race ();} Cela semble très merveilleux, mais cela entraînera inévitablement l'exception de l'exception à plusieurs reprises. Dans le même temps, il viole le «principe de distribution des responsabilités des classes» et est une mauvaise conception. L'enregistrement des exceptions n'appartient pas au comportement des classes d'exception et l'enregistrement des exceptions doit être effectué par un système de journalisation spécial. Et les informations d'enregistrement anormales changent constamment. Nous enregistrons des exceptions qui devraient fournir des informations plus riches. Cela nous aide à trouver la cause profonde du problème en fonction des informations d'exception pour résoudre le problème.
Bien que nous ayons beaucoup discuté de l'enregistrement des exceptions, trop l'accent sur ces développeurs rend les développeurs plus confus. Un bon moyen est de fournir un cadre d'exception de gestion du système. Le cadre décide de l'enregistrement des exceptions et comment enregistrer des exceptions. Ce n'est pas à la hauteur des programmeurs ordinaires de décider. Mais il est avantageux de savoir quelque chose.
5. Gestion des exceptions dans le projet J2EE
À l'heure actuelle, les projets J2EE sont généralement divisés en plusieurs couches logiquement. Les classiques sont divisés en trois couches: couche de présentation, couche commerciale et couche d'intégration (y compris l'accès à la base de données et l'accès au système externe).
Le projet J2EE a sa complexité, et plusieurs problèmes doivent être accordés à une attention particulière lors de la gestion des exceptions dans le projet J2EE.
Lorsque nous utilisons des applications distribuées, nous rencontrons de nombreuses exceptions vérifiées. Tous les appels RMI (y compris les appels d'interface distante EJB) jetteront Java.rmi.RemoteException; Dans le même temps, RemoteException est une exception vérifiée. Lorsque nous passons des appels distants dans le système commercial, nous devons tous rédiger une grande quantité de code pour gérer ces exceptions vérifiées. Une fois la RemoteException, ces exceptions vérifiées sont très graves pour le système, et il n'y a presque aucune possibilité de réessayer. En d'autres termes, lorsque ces terribles exceptions vérifiées telles que RemoteException apparaissent, nous n'avons pas besoin de réessayer, mais nous devons écrire beaucoup d'essais ... Catch Code pour le gérer. Généralement, nous faisons des appels RMI au niveau inférieur. Tant qu'il y a un appel RMI, toutes les interfaces de niveau supérieur nécessiteront un RemoteException à lancer. Parce que la façon dont nous traitons avec RemoteException est de continuer à le lancer. Cela détruira notre interface commerciale. RemoteException Ces exceptions au niveau du système J2EE affectent sérieusement nos interfaces commerciales. Le but de notre superposition des systèmes est de réduire la dépendance entre les systèmes, et les changements technologiques dans chaque couche n'affecteront pas d'autres couches.
// classe publique UsersoAmplimples Usersoa {public userInfo getUserRinfo (String userId) lance RemoteException {//… Méthode distante appelle.//…… }.public Interface UserManager {public userInfo getUserRinfo (String userId) lance RemoteException;} userInfo getUserRinfo (String Userid) De même, JDBC Access lancera une exception vérifiée de SQLEXception.
Afin d'éviter l'intrusion profonde des exceptions vérifiées au niveau du système dans le système commercial, nous pouvons définir l'exception d'un système commercial pour la méthode commerciale. Pour des exceptions très sérieuses telles que SQLEXception et RemoteException, nous pouvons définir une nouvelle exception non contrôlée, puis encapsuler la sqlexception et la RemoteException dans une exception non contrôlée et la lancer.
Si cette exception au niveau du système doit être remise à l'appelant précédent pour gérer, vous pouvez nouvellement définir une exception commerciale vérifiée, puis sceller l'exception au niveau du système dans une exception au niveau commercial, puis le lancer.
Généralement, nous devons définir une exception non contrôlée, afin que toutes les méthodes de l'interface de couche d'intégration déclarent lancer cette exception non contrôlée.
public DataAccessExceptionExtend RuntimeException {...} Interface publique UserDao {public String getPassword (String userId) lève DataAccessException;} public class userDaOIMPLIMPLES UserDao {public String getPassword (String userId) lance DataAcssexception {String sql = "SELECT MOTWAYSOR '"+ userId +"' "; essayez {… // jdbc appelle S.ExecuteQuery (SQL);…} catch (SQException ex) {throw new DataAccessException (" Database Query a échoué "+ sql, ex);}}} Définissez une exception commerciale vérifiée, afin que toutes les méthodes de l'interface de couche commerciale déclarent lancer une exception vérifiée.
classe publique BusinessExceptionExtend exception {… ..} interface publique Usermanager {public userInfo copyUserInfo (userInfo User) lève BusinessException {userInfo newUser = null; try {newUser = (userInfo) user.clone ();} Catch (la méthode ClonenupportException ex) {Throw New BusinessException ("la méthode ClonenuPortException Ex) {Throw pris en charge: "+ userInfo.class.getName (), ex);}}} La couche de représentation J2EE doit être une couche très mince, et ses principales fonctions sont les suivantes: obtenir des demandes de page, assembler les paramètres de la page dans des objets POJO, appeler les méthodes commerciales correspondantes, puis transmettre la page, présenter les données commerciales correspondantes à la page. La couche de présentation doit faire attention à un problème. La couche de présentation doit vérifier la légitimité des données, comme certains champs d'entrée ne peuvent pas être vides, la vérification de la longueur des caractères, etc.
Tous les paramètres passés de J2EE à l'arrière-plan de la page sont le type de caractère. Si vous avez besoin de l'entrée des paramètres de type numérique ou de date, la valeur de caractères doit être convertie en valeur numérique ou date correspondante.
Si les paramètres de vérification du code de la couche de représentation ne sont pas valides, il doit être renvoyé à la page d'origine, permettant à l'utilisateur de réintégrer les données et d'inviter des informations d'erreur pertinentes.
Habituellement, un paramètre passé de la page est converti en valeur numérique, nous pouvons voir un tel code
ModeandView handleRequest (HttpServLetRequest Request, HttpServletResponse Response) lève une exception {String Agestr = request.getParAmètre ("Age"); int Age = Integer.Parse (Agestr); ……… String anniversairetr = request.getParameter ("anniversaire"); Format SimpledateFormat = new SimpledateFormat ("mm / dd / yyyy"); date d'anniversaire = format.parse (anniversairestr);} Le code ci-dessus doit être vu souvent, mais lorsque l'utilisateur entre un caractère qui ne peut pas être converti en un entier à partir de la page ou d'une valeur de date incorrecte.
La méthode Integer.Parse () est jetée une exception non contrôlée avec NumberFormatexception. Cependant, cette exception n'est certainement pas une exception fatale. Généralement, lorsque la valeur saisie par l'utilisateur dans le champ d'entrée de page est illégale, nous devons inciter l'utilisateur à rentrer. Mais une fois qu'une exception non contrôlée est lancée, il n'y a aucune chance de réessayer. Des codes comme celui-ci provoquent une grande quantité d'informations d'exception à afficher sur la page. Rendez notre système très fragile.
De même, la méthode SimpledateFormat.Parse () lèvera également une exception non contrôlée de ParseException.
Dans ce cas, nous devons prendre ces exceptions non contrôlées et inciter l'utilisateur à rentrer.
ModeandView handleRequest (httpsservletRequest request, httpservletResponse réponse) lève exception {String Agestr = request.getParameter ("Age"); String anniversaireStr = request.getParameter ("anniversaire"); int age = 0; date anniversaire = null; try. ex){error.reject("age","is not a legal integer value");}………try{SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy");birthDay = format.parse(birthDayStr);}catch(ParseException ex){error.reject("birthDay","is not a legal date, please enter the date in Format 'mm / dd / yyy');}} À la couche de présentation, vous devez déterminer si la méthode d'appel lancera une exception non contrôlée, dans quelles circonstances ces exceptions seront-elles jetées et effectueront le traitement correct.
Dans la couche de présentation, il n'est pas nécessaire de prendre des exceptions en général. Si l'exception lancée par la méthode commerciale appelée équivaut à la deuxième valeur de retour, dans ce cas, il est nécessaire de capturer.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.