¿Por qué hablar sobre el manejo de excepciones en el proyecto J2EE? Tal vez muchos principiantes de Java quieren decir: "¿No es el manejo de la excepción solo intente ... atrapar ... finalmente? ¡Todos saben esto!" El autor también piensa de esta manera cuando está aprendiendo por primera vez a Java. ¿Cómo definir la clase de excepción correspondiente en un proyecto J2EE de múltiples capas? ¿Cómo manejar las excepciones en cada capa del proyecto? ¿Cuándo se lanza la excepción? ¿Cuándo se registra la excepción? ¿Cómo grabar excepciones? ¿Cuándo debo convertir la excepción marcada en una excepción sin control, y cuándo debo convertir la excepción sin control en una excepción verificada? ¿Debería presentarse la excepción a la página frontal? ¿Cómo diseñar un marco de excepción? Estos temas se discutirán en este artículo.
1. Manejo de excepciones de Java
En los lenguajes de programación de procedimientos, podemos determinar si el método se ejecuta normalmente devolviendo el valor. Por ejemplo, en un programa escrito en el lenguaje C, si el método se ejecuta correctamente, devolverá 1. Si el error se ejecuta, devolverá 0. En una aplicación desarrollada por VB o Delphi, cuando ocurra un error, apareceremos un cuadro de mensaje al usuario.
No podemos obtener los detalles del error a través del valor de retorno del método. Puede deberse a que el método está escrito por diferentes programadores, cuando ocurre el mismo tipo de error en diferentes métodos, los resultados devueltos y la información de error no son consistentes.
Por lo tanto, el lenguaje Java adopta un mecanismo de manejo de excepciones unificadas.
¿Qué es una excepción? Errores capacitables y procesables que ocurren en tiempo de ejecución.
En el idioma Java, la excepción es la clase principal de todas las excepciones. Cualquier excepción se extiende a la clase de excepción. La excepción es equivalente a un tipo de error. Si desea definir un nuevo tipo de error, extienda una nueva subclase de excepción. La ventaja de usar excepciones es que puede ubicar con precisión la ubicación del código fuente que causa el error del programa y obtener información de error detallada.
El manejo de excepciones de Java se implementa a través de cinco palabras clave, intente, atrapa, tira, tira, finalmente. La estructura de manejo de excepciones específica es implementada por el intento ... .Catch .... Las declaraciones Java de almacenamiento de bloques TRY que pueden tener excepciones. La captura se usa para atrapar la ocurrencia de excepciones y manejar las excepciones. El bloque final se utiliza para borrar los recursos no libres en el programa. El bloque final siempre se ejecuta si el código que no administra cómo regresa el bloque de try.
Un código de manejo de excepción típico
public String getPassword (String UserId) lanza DataAccessException {String sql = "Seleccione contraseña de UserInfo donde userId = '" +userId +"'"; string contraseña = null; conexión con = null; instrucciones s = null; resultset rs = null; try {con = getConnection (); // get data Connections s = con.createmement (); rs = ss = ss = s.exy (sqequery (squty (squty (squty (squtyer while (rs.next ()) {contraseña = rs.getString (1);} rs.close (); s.close ();} capt (sqlexception ex) {throw new dataAccessEsexception (ex);} finalmente {try {if (conoss = null) {con.close ();}} Catch (sqlexception) {shrew shuse sqlex) {neoceCessexception ("", ",", ",", ",", ", se activa (sqlException SQLECT. falló! ", sqlex);}} return contraseña;} Se puede ver que las ventajas del mecanismo de manejo de excepciones de Java:
El error se clasifica de manera uniforme e implementa extendiendo la clase de excepción o su subclase. Esto evita que el mismo error pueda tener diferentes mensajes de error en diferentes métodos. Cuando se produce el mismo error en diferentes métodos, solo necesita lanzar el mismo objeto de excepción.
Obtenga información de error más detallada. A través de clases de excepción, la información de error se puede dar a la excepción que es más detallada y más útil para el usuario. Fácil para los usuarios rastrear y depurar programas.
Separe el resultado de retorno correcto del mensaje de error. Reduce la complejidad del programa. La persona que llama no necesita saber más sobre el resultado de retorno.
Obliga a la persona que llama a manejar excepciones para mejorar la calidad del programa. Cuando una declaración de método necesita lanzar una excepción, la persona que llama debe usar el bloque de try ... Catch para manejar la excepción. Por supuesto, la persona que llama también puede permitir que la excepción continúe lanzándose al nivel superior.
2. Excepción verificada o excepción sin control?
Las excepciones de Java se dividen en dos categorías: excepción verificada y excepción sin control. Todas las excepciones que heredan java.lang.Exception pertenecen a excepciones verificadas. Todas las excepciones que heredan java.lang.runtimeexception pertenecen a excepciones sin control.
Cuando un método llama a un método que puede lanzar una excepción verificada, la excepción debe capturarse y procesarse o volver a crecer a través del bloque de captura Try ...
Echemos un vistazo a la declaración del método CreateStatement () de la interfaz de conexión.
Declaración pública createStatement () lanza SQLException; SQLException es una excepción verificada. Cuando se llama al método de creatatación, Java obliga a la persona que llama a capturar la SQLException. public String getPassword (String UserId) {try {... Declaración s = Con.CreateStatement (); ... Catch (SQLException Sqlex) {...} ...} o
public String GetPassword (String UserId) lanza SQLException {Declaración s = Con.CreateStatement ();} (Por supuesto, los recursos como la conexión y la satisfacción deben cerrarse a tiempo. Esto es solo para ilustrar que la excepción verificada debe obligar a la persona que llama a atrapar o continuar lanzando)
La excepción sin control también se llama excepción de tiempo de ejecución. Por lo general, RuntimeException indica una excepción que el usuario no puede recuperarse, como la incapacidad de obtener una conexión de base de datos, la incapacidad de abrir un archivo, etc. Aunque el usuario también puede atrapar excepciones sin control como manejar las excepciones verificadas. Pero si la persona que llama no capta la excepción sin control, el compilador no lo obligará a hacerlo.
Por ejemplo, un código que convierte los caracteres en valores enteros es el siguiente:
Cadena str = "123"; int value = Integer.ParseInt (str);
La firma del método de parseint es:
Public staticint parseint (String s) lanza numberFormateException
Cuando los parámetros pasados no se pueden convertir en el entero correspondiente, se lanzará una información numnformatException. Debido a que NumberFormAxception se extiende a RuntimeException, es una excepción sin control. Por lo tanto, no hay necesidad de intentarlo ... atrapar al llamar al método de Parseint
Porque Java no obliga a la persona que llama a atrapar o lanzar la excepción sin control. Por lo tanto, a los programadores siempre les gusta lanzar excepciones sin control. O cuando se necesita una nueva clase de excepción, siempre se usa para extenderse desde RuntimeException. Cuando llame a estos métodos, si no hay un bloque de captura correspondiente, el compilador siempre le permitirá pasar, y no necesita comprender qué excepción lanzará este método. Parece que esta es una buena idea, pero hacerlo está lejos de la intención real del manejo de excepciones de Java. Y es engañoso para el programador que llama a su clase, porque la persona que llama no tiene idea en qué circunstancias necesita para manejar las excepciones. La excepción verificada puede decirle claramente a la persona que llama qué excepciones deben manejarse al llamar a esta clase. Si la persona que llama no lo procesa, el compilador solicitará y no puede compilar y pasar. Por supuesto, cómo lidiar con él depende de la persona que llama decidir.
Por lo tanto, Java recomienda que las personas deban usar excepciones verificadas en su código de aplicación. Al igual que mencionamos en la sección anterior que la ventaja de usar excepciones es que puede obligar a la persona que llama a manejar las excepciones que se generarán. Las excepciones verificadas se utilizan como estándar en documentos oficiales de Java, como "Tutorial Java".
El uso de excepciones verificadas debería significar que hay muchas pruebas ... capturas en su código. Después de escribir y manejar más y más intentos ... atrapar bloques, muchas personas finalmente comenzaron a preguntarse si las excepciones verificadas deberían usarse como estándar.
Incluso Bruce Eckel, el autor del famoso "Pensamiento en Java", cambió sus pensamientos anteriores. Bruce Eckel incluso aboga por usar excepciones sin control como uso estándar. Y publique un artículo para probar si la excepción verificada debe eliminarse de Java. Bruce Eckel: "Cuando una pequeña cantidad de código, las excepciones verificadas son, sin duda, un concepto muy elegante y ayudan a evitar muchos errores potenciales. Pero la experiencia muestra que el resultado es exactamente lo contrario para una gran cantidad de código".
Para discusiones detalladas sobre excepciones verificadas y excepciones sin control, consulte
Tutorial de Java http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
El uso de excepciones verificadas puede causar muchos problemas.
La excepción verificada causa demasiado intento ... Code Code
Puede haber muchas excepciones verificadas que los desarrolladores no pueden manejar razonablemente, como SQLException. Pero los desarrolladores tienen que intentar ... atrapar. Cuando los desarrolladores no pueden manejar una excepción marcada correctamente, generalmente simplemente imprimen la excepción o no hacen nada. Especialmente para los novatos, demasiadas excepciones controladas lo hacen sentir perdido.
Pruebe {... Declaración S = Con.CreateStatement (); ... Catch (Sqlexception Sqlex) {sqlex.printstackTrace ();} o
Pruebe {... Declaración S = Con.CreateStatement (); ... Catch (Sqlexception sqlex) {// no hacer nada} La excepción verificada causa muchas generaciones de código difíciles de entender
Cuando los desarrolladores tienen que ver una excepción verificada que no pueden manejar correctamente, generalmente se vuelven a empaquetar en una nueva excepción y luego se lanzan. Hacerlo no aporta ningún beneficio al programa. En cambio, hace que el código sea difícil de entender más tarde.
Al igual que usamos el código JDBC, hay mucho intento ... atrapar. El código realmente útil está incluido en Try ... Catch. Haciendo que sea difícil entender este método
La excepción verificada hace que la excepción se encapsule constantemente en otra excepción de clase y luego se arroje
public void Methoda () lanza excepcionA {... ..throw New ExceptionA ();} public void Methodb () lanza excepcionB {try {método (); ...} catch (excepcionA ex) {throw new ExceptionB (ex);}} public void Methodc (), excepto} {trey {métodob (); ...} Catch (excepcionB ex) {droga new Newcexceptc (ex); Vemos que la excepción está encapsulada y rehacer la capa por capa.
La excepción verificada causa la corrupción del método de interfaz
Un método en una interfaz ha sido utilizado por múltiples clases. Cuando se agrega una excepción verificada adicional a este método, todos los códigos que llaman a este método deben modificarse.
Se puede ver que los problemas anteriores se ven obligados a atrapar y procesar porque la persona que llama no puede manejar la excepción verificada correctamente, y se ven obligados a encapsular y luego volver a sacar. Esto es muy inconveniente y no trae ningún beneficio. En este caso, generalmente se usan excepciones sin control.
La excepción verificada no es todo. La excepción verificada es mucho más fácil de usar que el valor de retorno de errores de la programación tradicional. Es mucho mejor asegurarse de que las excepciones se manejen correctamente a través del compilador que juzgar por el valor de devolución.
Si una excepción es fatal, es irrecuperable. O la persona que llama va a atraparlo sin ningún beneficio, use la excepción sin control.
Si la persona que llama puede recuperar una excepción y puede manejarse correctamente, use la excepción verificada.
Cuando se usa una excepción sin control, la excepción no ecológica que el método puede lanzar debe describirse en detalle en la declaración del método. La persona que llama decide si atrapar la excepción sin control
¿Cuándo usar excepciones verificadas y cuándo usar excepciones sin control? No hay estándar absoluto. Pero puedo dar algunas sugerencias
Cuando todas las personas que llaman tienen que manejar esta excepción, la persona que llama puede volver a intentar la operación; o la excepción es equivalente al segundo valor de retorno del método. Utilice la excepción verificada.
Esta excepción solo puede ser manejada por unas pocas personas que llaman más avanzadas, y las personas que llaman comunes no pueden manejarla correctamente. Use una excepción sin control. Las personas que llaman que tienen la capacidad de procesar pueden realizar un procesamiento avanzado, pero generalmente las personas que llaman no lo manejan en absoluto.
Esta excepción es un error muy grave, como errores de conexión de la base de datos, falla del archivo para abrir, etc. o estas excepciones están relacionadas con el entorno externo. No es posible resolver el problema de volver a intentar. Use una excepción sin control. Porque una vez que ocurre esta excepción, la persona que llama no puede manejarla en absoluto.
Si no es seguro, use una excepción sin control. Y describa en detalle la excepción que se puede lanzar para permitir que la persona que llama decida si manejarla.
3. Diseñe una nueva clase de excepción
Al diseñar una nueva clase de excepción, primero verifique si esta clase de excepción es realmente necesaria. En términos generales, trate de no diseñar nuevas clases de excepción, pero trate de usar clases de excepción que ya existan en Java.
como
IlegalargumentException, no apoyo a la operación.
Ya sea la nueva excepción, una excepción Chequed o una excepción sin control. Todos tenemos que considerar el problema de anidación de las excepciones.
public void Methoda () lanza excepcionA {... ... a través de una nueva excepción ();} Método Declaración del método arroja excepciona.
Public void Methodb () lanza excepcionb
Methodb Declaration lanzará ExceptionB. Cuando se llama a MethodA en el método Methodb, se puede procesar ExceptionA, por lo que ExceptionA debería continuar vomitando. Una forma es hacer que el método B Declaration Throw ExceptionA. Pero esto ha cambiado la firma del método del métodob. Una vez cambiado, se deben cambiar todos los métodos que llamen métodob.
Otra forma es encapsular la excepción en ExceptionB y luego arrojarlo. Si no encapsulamos la excepción en ExceptionB, perderemos la información de la excepción raíz, lo que hace que sea imposible rastrear la fuente original de la excepción.
public void Methodb () lanza ExceptionB {try {MethodA (); ...} Catch (ExceptionA Ex) {Throw New ExceptionB (ex);}} Como en el código anterior, ExceptionB anesta una excepción. Llamaremos a ExceptionA "causó una excepción" por el momento, porque la excepción hace que ocurra la excepciónB. Esto evitará que se pierda la información de excepción.
Entonces, cuando definimos una nueva clase de excepción, debemos proporcionar dicho constructor que pueda contener excepciones anidadas. Y hay un miembro privado para guardar esta "excepción de causa".
public class ExceptionB extiende la excepción {causa de lanzamiento privada; public ExceptionB (String Msg, Throwable Ex) {Super (msg); this.Cause = ex;} public ExceptionB (String MSG) {super (msg);} public ExceptionB (showable EX) {this.Cause = ex;}} Por supuesto, cuando llamamos al método PrintStackTrace, necesitamos imprimir toda la información de "excepción de excepción" al mismo tiempo. Por lo tanto, necesitamos anular el método PrintStackTrace para mostrar todas las trazas de la pila de excepciones. Incluye rastros de pila de excepciones anidadas.
public void printStackTrace (printStrean PS) {if (causa == null) {super.printstacktrace (ps);} else {ps.println (this); causa.printstacktrace (ps);}} Un soporte completo para el código fuente de la clase de excepción marcada anidada es el siguiente. Llamémoslo NestedException aquí por el momento
public NestedException extiende la excepción {causa privada de lanzamiento; public NestedException (string msg) {super (msg);} public NestedException (string msg, showable ex) {super (msg); this.Cause = ex;} public showable getCause () {return (this.Cause == null? this: this.cause);} public getMessage () {string string striE super.getMessage (); showable causa = getCause (); if (causa! = null) {mensaje = mensaje + "; la excepción anidada es" + causa;} Mensaje de retorno;} 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 () {printStackTrace (System.Error);}}Además, debe diseñar una clase de excepción sin control como se indicó anteriormente. Solo necesita heredar RuntimeException.
4. Cómo registrar las excepciones
Como un gran sistema de aplicación, se requieren archivos de registro para registrar la operación del sistema para facilitar el seguimiento y la grabación de la operación del sistema. Las excepciones que ocurren en el sistema naturalmente deben registrarse en el sistema de registro.
public String getPassword (String UserId) lanza NosuchUserException {userInfo user = userDao.QueryUserById (userId); if (user == null) {logger.info ("La información del usuario no se puede encontrar, userId ="+userId); tire nosuchuserException ("La información del usuario no se puede encontrar, userid ="+userid;};};};} user.getPassword ();}} public void sendUserPassword (String UserId) lanza la excepción {userInfo user = null; try {user = getPassword (userId); // ... ..sendmail (); //} Catch (NosuchuseRexception ex) (logger.error ("Esta información de usuario no se puede encontrar:"+Userid+ex); Show New Exception (ex);};};};};};};};};};} Notamos que un error se registró dos veces. En el origen del error solo grabamos en el nivel de información. En el método SenduserPassword, también registramos toda la información de excepción.
El autor ha visto muchos proyectos de excepciones de registro de esta manera, independientemente de 3721, y toda la excepción se registrará solo cuando se encuentre una excepción. Si una excepción se encapsula y se arroja continuamente varias veces, se registrará varias veces. Entonces, ¿dónde se debe grabar la excepción?
¡La excepción debe grabarse en la ubicación inicial!
Si tiene que atrapar una excepción que no se puede manejar correctamente, simplemente encapsularla en otra excepción y tirarla. No hay necesidad de grabar la excepción grabada nuevamente.
Si se atrapa una excepción, esta excepción se puede manejar. No se deben grabar excepciones
Public Date getDate (String Str) {date ApplyDate = NULL; SimpleDateFormat Format = new SimpleDateFormat ("MM/DD/YYYY"); intente {ApplyDate = Format.Parse (ApplyDatestr);} Catch (ParseException ex) {// por qué, cuando el formato está mal, devuelve nulo} Aplicar aplicada;} Cuando se atrapa una excepción no registrada o una excepción del sistema externo, se deben registrar los detalles de la excepción.
Pruebe {... String sql = ”select * de UserInfo”; Declaración s = Con.CreateStatement (); ... Catch (SqLException SQLEX) {logger.error ("Error de ejecución SQL"+SQL+SQLEX);} Dónde registrar información de excepción y cómo registrar la información de excepción puede ser una cuestión de opinión. Algunos sistemas incluso permiten excepciones de registro de clase de excepción. Cuando se genera un nuevo objeto de excepción, la información de excepción se registra automáticamente.
public class BusinessException extiende la excepción {private void logTrace () {StringBuffer buffer = new StringBuffer (); Buffer.Append ("Error empresarial en la clase:"); buffer.append (getClassName ()); buffer.append (", método:"); buffer.append (getMethodName (); buffer.append (", Message: Message:": " "); buffer.append (this.getMessage ()); logger.error (buffer.ToString ());} public BusinessException (String s) {super (s); race ();} Esto parece ser muy maravilloso, pero inevitablemente conducirá a que la excepción se grabe repetidamente. Al mismo tiempo, viola el "principio de distribución de responsabilidades de las clases" y es un mal diseño. La grabación de excepciones no pertenece al comportamiento de la clase de excepción, y las excepciones de grabación deben ser realizadas mediante un sistema de registro especial. Y la información de grabación anormal cambia constantemente. Estamos grabando excepciones que deberían dar información más rica. Esto nos ayuda a encontrar la causa raíz del problema en función de la información de excepción para resolver el problema.
Aunque hemos discutido mucho sobre la grabación de excepciones, demasiado énfasis en esto hace que los desarrolladores sean más confundidos. Una buena manera es proporcionar un marco de manejo de excepciones para el sistema. El marco decide si registrar excepciones y cómo grabar excepciones. No depende de los programadores comunes decidir. Pero es beneficioso saber algo.
5. Manejo de excepciones en el proyecto J2EE
En la actualidad, los proyectos J2EE generalmente se dividen en múltiples capas lógicamente. Los clásicos se dividen en tres capas: capa de presentación, capa de negocios y capa de integración (incluido el acceso a la base de datos y el acceso al sistema externo).
El proyecto J2EE tiene su complejidad, y varios problemas deben recibir especial atención al manejar excepciones en el proyecto J2EE.
Cuando utilizamos aplicaciones distribuidas, encontramos muchas excepciones verificadas. Todas las llamadas RMI (incluidas las llamadas de interfaz remota de EJB) lanzarán java.rmi.remoteException; Al mismo tiempo, RemoteException es una excepción verificada. Cuando hacemos llamadas remotas en el sistema comercial, todos necesitamos escribir una gran cantidad de código para manejar estas excepciones verificadas. Una vez que se produce la reducción remota, estas excepciones verificadas son muy graves para el sistema, y casi no hay posibilidad de volver a intentarlo. En otras palabras, cuando aparecen estas terribles excepciones verificadas como RemoteException, no tenemos ninguna necesidad de volver a intentarlo, pero tenemos que escribir mucho Código de prueba ... para manejarlo. En general, hacemos llamadas RMI en el nivel inferior. Mientras haya una llamada RMI, todas las interfaces de nivel superior requerirán que se lance una remota. Porque la forma en que tratamos con RemoteException es continuar vomitándolo. Esto destruirá nuestra interfaz comercial. RemoteException Estas excepciones a nivel de sistema J2EE afectan seriamente nuestras interfaces comerciales. El propósito de nuestras capas de sistemas es reducir la dependencia entre los sistemas, y los cambios tecnológicos en cada capa no afectarán otras capas.
// clase pública UserSoAimPlImples Useroa {public UserInfo getUserInfo (String) lanza RemoteException {//… Método remoto Call./.……h}public Public Usermanager {public userInfo getUserInfo (String userId) lanza remoteexception;} Del mismo modo, JDBC Access lanzará una excepción verificada de SQLException.
Para evitar la profunda intrusión de las excepciones verificadas a nivel de sistema en el sistema comercial, podemos definir la propia excepción de un sistema comercial para el método comercial. Para excepciones muy serias como SQLException y RemoteException, podemos definir una nueva excepción sin control, y luego encapsular SQLException y RemoteException en una excepción sin control y lanzarla.
Si esta excepción a nivel del sistema se debe entregar a la persona que llama anterior para manejar, puede definir recientemente una excepción comercial verificada y luego sellar la excepción a nivel de sistema en una excepción de nivel comercial y luego tirarla.
En general, necesitamos definir una excepción sin control, de modo que todos los métodos de la interfaz de la capa de integración declaren que lanzar esta excepción sin control.
Public dataAccessExceptionExtends runtimeException {...} interfaz pública userDao {public String getPassword (String UserId) lanza DataAccessException;} public class UserDaoMplimples UserDao {public String GetPassword (String UserId) lanza DataCcessException {String sql = "Seleccionar contraseña de userInfo dondeDID = = = =" '"+userId+"' "; try {... // jdbc llama s.ExecuteQuery (sql); ...} capt (sqlexception ex) {throw new dataAccessException (" Falló la consulta de la base de datos "+sql, ex);}}} Defina una excepción comercial verificada, de modo que todos los métodos de la interfaz de la capa de negocios declaren una excepción verificada.
public class BusinessExceptionExtendes Exception {... ..} Interfaz pública USERMANAGER {public UserInfo CopyUserInfo (UserInfo User) lanza BusinessException {UserInfo NewUser = null; try {Newuser = (UserInfo) User.Clone ();} compatible: "+userInfo.class.getName (), ex);}}} La capa de representación J2EE debe ser una capa muy delgada, y sus funciones principales son: obtener solicitudes de página, ensamblar los parámetros de la página en los objetos POJO, llamar a los métodos comerciales correspondientes y luego reenviar la página, presentar los datos comerciales correspondientes a la página. La capa de presentación debe prestar atención a un problema. La capa de presentación debe verificar la legitimidad de los datos, como algunos campos de entrada, no puede estar vacío, la verificación de la longitud del carácter, etc.
Todos los parámetros pasados de J2EE al fondo desde la página son de tipo de caracteres. Si requiere la entrada de parámetros numéricos o de tipo de fecha, el valor del carácter debe convertirse al valor numérico o de fecha correspondiente.
Si los parámetros de verificación del código de la capa de representación no son válidos, debe devolverse a la página original, permitiendo al usuario volver a ingresar los datos y solicitar información de error relevante.
Por lo general, un parámetro que se pasa de la página se convierte en un valor numérico, podemos ver dicho código
ModeandView HandLerequest (httpservletRequest solicitud, httpservletResponse respuesta) arroja excepción {string agestr = request.getParameter ("edad"); int age = integer.parse (agest); ……… cadena birthdlestr = request.getParameter ("cumpleaños"); SimpleDateFormat Format = new SimpleDateFormat ("mm/dd/yyyy"); fecha de cumpleaños = format.parse (birthdlestr);} El código anterior debe verse a menudo, pero cuando el usuario ingresa a un carácter que no puede convertirse en un entero desde la página o un valor de fecha incorrecto.
El método Integer.Parse () se arroja una excepción sin control con NumberFormateException. Sin embargo, esta excepción definitivamente no es una excepción fatal. En general, cuando el valor ingresado por el usuario en el campo de entrada de la página es ilegal, debemos solicitar al usuario que vuelva a ingresar. Pero una vez que se lanza una excepción sin control, no hay posibilidad de volver a intentarlo. Los códigos como este causan que se muestre una gran cantidad de información de excepción en la página. Haga que nuestro sistema se vea muy frágil.
Del mismo modo, el método SimpleDateFormat.Parse () también lanzará una excepción sin control de ParseException.
En este caso, debemos atrapar estas excepciones sin control y pedirle al usuario que vuelva a ingresar.
ModeandView handLerequest (httpservletRequest solicitud, httpservletResponse respuesta) lanza excepción {string agestr = request.getParameter ("edad"); string birthreblestr = request.getParameter ("cumpleaños"); int age = 0; fecha = null; ex) {error.reject ("edad", "no es un valor entero legal");} ……… intente {simpledateFormat format = new SimpleDateFormat ("mm/dd/yyyy"); cumpleaños = format.parse (birthdlestr);} capsexception ex) {error.reject ("cumpleaños", "no es una fecha legal, por favor ingrese la fecha de la fecha/mm/dhd/dhd/dhyy/dhyy ' formato ");}} En la capa de presentación, debe averiguar si el método de llamada lanzará una excepción sin control, bajo qué circunstancias se lanzarán estas excepciones y realizarán el procesamiento correcto.
En la capa de presentación, no hay necesidad de atrapar excepciones en general. Si la excepción presentada por el método comercial llamado es equivalente al segundo valor de retorno, en este caso es necesario capturar.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.