EXCEPCIONES - MEJORES PRÁCTICAS

Mejores prácticas para el manejo de excepciones

Amigos, hemos estado utilizando el manejo de excepciones en nuestro código para casi todas las aplicaciones estándar de la industria. Enfoque habitual es crear algunas clases de excepciones personalizadas que se extienden de la base Excepción clase. En este post, voy a sugerir otro enfoque que pudiera hacerle más sentido.

Secciones de este mensaje:

• Nuestro nuevo enfoque
• Ventajas

Nuestro nuevo enfoque

Probablemente algunos de nosotros ya utilizan este mecanismo. Si usted es uno de ellos, entonces por favor revise este post y sugerir las mejoras. De lo contrario, aprender sobre este mecanismo y sus comentarios.

Nuestro nuevo enfoque utiliza las clases internas estáticas para cada nuevo escenario excepcional .Tradicionalmente, creamos una clase DBException extendiendo la clase Exception. Ahora, cada vez que nos vemos atrapados en una situación en la que es necesario que excepción lanzada, solemos crear una instancia de esta clase, poner un poco de información en forma de mensaje, y echarlo.

Ahora, vamos a considerar que hay situaciones siguientes que hemos identificado en el que tenemos que tirar DBException:

1. Error de ejecución del SQL
2. No existen datos en la que esperamos al menos una fila
3. Existen múltiples filas en la que esperamos fila único single
4. Error parámetros no válido

y pueden existir muchos más de tales casos.

Diferentes con nuestro enfoque tradicional, y mucho, prueba nuestro nuevo enfoque, es decir crear las clases internas estáticas.

Vamos a empezar con la clase BaseException que se crea como abstracto y será el tratamiento super clase de todas las clases de excepción.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// Make this class abstract so that developers are forced to create // suitable exception types only public abstract class BaseException extends Exception{     //Each exception message will be hold here     private String message;     public BaseException(String msg)     {         this.message = msg;     }     //Message can be retrieved using this accessor method     public String getMessage() {         return message;     } }

No es el momento de crear nuevas clases internas de excepción. Deje que golpeó el teclado.

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

public class DBExeption {     //SQL execution error     public static class BadExecution extends BaseException     {         private static final long serialVersionUID = 3555714415375055302L;         public BadExecution(String msg) {             super(msg);         }     }     //No data exist where we expect at least one row     public static class NoData extends BaseException     {         private static final long serialVersionUID = 8777415230393628334L;         public NoData(String msg) {             super(msg);         }     }     //Multiple rows exist where we expect only single row     public static class MoreData extends BaseException     {         private static final long serialVersionUID = -3987707665150073980L;         public MoreData(String msg) {             super(msg);         }     }     //Invalid parameters error     public static class InvalidParam extends BaseException     {         private static final long serialVersionUID = 4235225697094262603L;         public InvalidParam(String msg) {             super(msg);         }     } }

Aquí, creamos una clase interna para cada escenario posible error identificado en el arranque. No puede haber muchos más extra. Depende de ti sólo para identificar y agregar más clases.

Veamos cómo estas clases parecen en archivos de registro.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public class TestExceptions {     public static void main(String[] args)     {         try         {             throw new DBExeption.NoData("No row found for id : x");         }         catch(Exception e)         {             e.printStackTrace();         }     } } Output: com.exception.DBExeption$NoData: No row found for id : x at com.test.TestExceptions.main(TestExceptions.java:7)

Como se puede ver el mensaje de registro de seguimiento de pila de excepción, si se ha vuelto más informativo.

Ventajas del uso de clases internas

1. Ventaja más importante es que si usted desarrollador ha escrito un texto de mensaje dudoso, entonces también se puede observar claramente que lo que era realmente malo.
2. Usted puede utilizar la instancia de comparación en diferentes situaciones en el que maneje diferentes escenarios excepcionales.
3. No es necesario enviar una sola excepción para un gran conjunto de condiciones excepcionales.
4. Es fácil de escribir casos de prueba de unidad para casos negativos donde se sabe la clase exacta excepción, debe esperar.
5. La tala es más significativo e informativo.

Espero que este post ha sido algunos informativa para usted. Si usted tiene algunas sugerencias, por favor escríbame.