Arquitectura CLARO-TECNOTREE CAPITULO 4: Excepciones Aplicaciones Java y Arquitectura CLARO-TECNOTREE CAPITULO 4: Excepciones

Excepciones Hablamos de excepciones cuando ocurrido el problema no se sabe que decisión tomar dentro del contexto que ocurrió el mismo. Una excepción es una situación inesperada o inusual que interrumpe el normal funcionamiento del programa.

Captura de excepciones y manejadores En Java se maneja el concepto de región segura, que consiste en un bloque enmarcado por la palabra try. Los manejadores se ocupan de tratar las excepciones lanzadas dentro del bloque try.

Captura de excepciones y manejadores Estructura del bloque try: try{ //código que puede provocar excepciones } catch(ClaseException1 ex1){ //Código que maneja excepciones de la clase ClaseException1 catch(ClaseException2 ex2){ //Código que maneja excepciones de la clase ClaseException2 catch(ClaseException3 ex3){ //Código que maneja excepciones de la clase ClaseException3

Captura de excepciones y manejadores En Java todas las clases de excepciones derivan de un ancestro por omisión que se llama Exception. Como cualquier excepción puede ser capturada por un manejador diseñado para esta clase . La clase Exception hereda de la clase Throwable, lo que permite que posea ciertas operaciones adicionales. Un método que debemos tener en cuenta es getMessage() que nos devuelve un String con una descripción de la excepción, lo que nos da más información sobre el error ocurrido y el método printStackTrace() que imprime la pila del error, el trace completo del error.

Captura de excepciones y manejadores public int division(int a,int b){ try{ return a/b; } catch(ArithmeticException ex1){ System.out.println(“Problema con division (ArithmeticException): “+ex1.getMessage()); ex1.printStackTrace(); return 0; catch(Exception ex2){ System.out.println(“Problema con division (Exception)”+ex2.getMessage()); ex2.printStackTrace();

Bloque de Finalización (finally) Luego de los manejadores (catch) de las excepciones existe una cláusula que contiene código que se ejecuta independientemente de que se hayan disparado o no excepciones. Esta cláusula es finally. La porción de código que se encuentra dentro de este bloque, se ejecuta luego de los manejadores y antes de que se lancen excepciones al contexto de nivel superior. try{ //código que puede provocar excepciones } catch(ClaseException1 ex1){ //Código que maneja excepciones de la clase ClaseException1 catch(ClaseException2 ex2){ //Código que maneja excepciones de la clase ClaseException2 finally{ //Código que se ejecuta siempre, haya o no ocurrido excepciones

Lanzamiento de Excepciones Nunca un módulo debe dar la impresión de que no pasó nada cuando algo ha fallado. La idea central es que el código que encuentra un problema y no lo pueda tratar, eleve o lance una excepción, que será atrapada o capturada por el módulo que invocó al método que está corriendo. MODULO 1 MODULO 2 MODULO 3 throw ex;

Lanzamiento de Excepciones Cuando se dispara una excepción se corta el hilo de ejecución normal y se eleva la excepción hacia el contexto superior que invocó el método. Quién toma el hilo de ejecución es ahora el manejador de excepciones del módulo invocante, y éste se ocupa de resolver el problema. También este último módulo puede volver a lanzar la excepción al próximo nivel superior, y así sucesivamente. Si la excepción no fuera capturada en ningún nivel, llegaría a salir del programa, abortándolo.

Lanzamiento de Excepciones Cuando un método arroja excepciones, en Java es obligatorio decir que excepciones puede arrojar, esto permite al cliente de la clase saber que excepciones debe manejar. Se usa la cláusula throws para realizar esta especificación: public void metodo(Persona p) throws Exception { try{ //código que puede provocar excepciones } catch(Exception ex2){ //captura las clases de excepciones del tipo Exception y sus descendientes System.out.println(“Excepción: “+ex2.getMessage()); throw ex2;

Lanzamiento de Excepciones Cuando un método arroja excepciones, en Java es obligatorio decir que excepciones puede arrojar, esto permite al cliente de la clase saber que excepciones debe manejar. Se usa la cláusula throws para realizar esta especificación: public void metodo(Persona p) throws Exception { try{ //código que puede provocar excepciones } catch(Exception ex2){ //captura las clases de excepciones del tipo Exception y sus descendientes System.out.println(“Excepción: “+ex2.getMessage()); throw ex2;

Lanzamiento de Excepciones Es correcta esta definición: public void metodo(Persona p) { try{ //código que puede provocar excepciones } catch(NullPointerException ex1){ System.out.println(“Referencia Null: “+ex1.getMessage()); // Elevamos la misma exception throw ex1;

Lanzamiento de Excepciones Analizar la siguiente definición: public void metodo(Persona p) throws Exception{ try{ if(p==null) throw new Exception(“Referencia Null”); //Código propio del método } catch(Exception ex1){ System.out.println(“Referencia Null: “+ex1.getMessage()); // Elevamos la misma exception throw ex1; En la línea que se lanza la excepción (throw new Exception(“Referencia Null”)), ¿se ejecuta lo que está dentro del manejador de excepciones para el tipo Exception?

Jerarquía de Excepciones en Java La base de la jerarquía es la clase Throwable, de esta clase extienden las clases Error y Exception. Las excepciones de clases descendientes de Error indican problemas muy serios e irrecuperables, por ejemplo algún problema interno de la JVM. Tampoco podremos capturarlas cuando usamos la cláusula catch para una Exception genérica, pues no derivan de esta clase. Tampoco son comprobadas, en el sentido de no se declaran en la cláusula throws. Debido a todo esto, vemos que no es bueno generar subclases de Error. Las excepciones de clases descendientes de Exception representan problemas que si se pueden tratar. Pero hay que tener cuidado cuando definimos nuestras propias excepciones, no deberíamos definirlas extendiéndolas de la clase RuntimeException, debido a que ni esta clase ni sus descendientes se declaran en cláusulas throws.

Jerarquía de Excepciones en Java Dentro del conjunto de todas las excepciones podemos hablar de excepciones no chequeadas y excepciones chequeadas. Las excepciones no chequeadas son aquellas excepciones que se producen por errores de programación y son producidas sólo en tiempo de ejecución, es decir, no podemos llegar a predecirlas, por ejemplo que se quiera acceder a una posición no válida de un vector. Si invocamos a un método que trabaja con un vector y este accede a una posición no valida, este método no tiene que declarar que puede lanzar esta excepción y aunque lo hiciera, cualquier otro método que lo invoque no está obligado a manejar excepciones de este tipo. Estas excepciones se corresponden con las subclases de RuntimeException y Error.

Jerarquía de Excepciones en Java Las excepciones chequeadas, obligan a los métodos que realizan operaciones que pueden provocar este tipo de excepciones a que deban declarar los manejadores correspondientes o declarar que pueden lanzarlas, y en este caso cualquier método que lo invoque está obligado a manejarlas o a volver a declarar que puede lanzar excepciones de este tipo. Si obviamos el manejo de este tipo de excepciones, el mismo compilador nos indica esta omisión, es decir, en tiempo de compilación se realiza este control.

Jerarquía de Excepciones en Java

Jerarquía de Excepciones en Java ArithmeticException Esta excepción se produce cuando se da una condición anormal del tipo aritmética. Por ejemplo una división por cero. NullPointerException Excepción que se produce cuando se quiere acceder a algún miembro de un objeto que aún no ha sido instanciado. ClassCastException Se produce cuando se quiere hacer el moldeo de un objeto a otra clase que no es válida. NegativeArraySizeException Se lanza cuando se quiere crear un array con un tamaño negativo. OutOfMemoryException Ocurre cuando intentamos instanciar un objeto y no hay memoria disponible.

Jerarquía de Excepciones en Java ArrayIndexOutOfBoundsException Se genera al intentar acceder a un elemento de un array más allá de los límites definidos inicialmente para ese array. NoClassDefFoundError Se intenta utilizar una clase que no está definida en el sistema. Existe una variable de sistema denominada CLASSPATH, que es donde se especifican las clases disponibles para que cualquier aplicación las consuma en tiempo de ejecución. Si en nuestra aplicación utilizamos una clase de alguna biblioteca y esta no está cargada en la variable CLASSPATH, en el momento utilizarla se lanzará esta excepción. InternalError Ocurre cuando se da un error inesperado a nivel de la máquina virtual. NoSuchMethodError Error que ocurre cuando se intenta acceder a un método de una clase, y el mismo no se encuentra definido.

Excepciones derivadas Al especificar los manejadores para las excepciones se deben tener en cuenta los siguiente: Primero deben ir los manejadores de las clases de excepciones de la base de la jerarquía y luego los manejadores de las demás clases que están más arriba. Cómo las excepciones se evalúan en orden, es un error poner un manejador de excepciones de una clase derivada luego del manejador de su clase base, dado que nunca se lo invocará. El orden en que se coloquen manejadores (bloques catch) tiene que ser tal, que cualquiera de ellos debe permitir alcanzar el siguiente, de lo contrario el compilador producirá un error.

Excepciones derivadas ¿Es correcta esta estructura? try{ //código que puede lanzar excepciones } catch(Exception ex){ //manejador para excepciones del tipo Exception catch(NullPointerException ex){ //manejador para excepciones del tipo NullPointerException

Definición de Excepciones propias Definir nuestras propias excepciones, nos permite indicar con precisión el tipo particular de error que un método puede elevar. public int division(int a, int b) throws Exception { if (b == 0) { throw new Exception("Divisor igual a cero"); } return a / b; En este método estamos retornando una instancia de la clase Exception cuando el divisor es cero. Pero esto no le permite al módulo que invoca al método determinar de qué error se trata, solo va a poder especificar un manejador para un Exception general.

Definición de Excepciones propias public int division(int a, int b) throws DivisorCeroException{ if (b == 0) { throw new DivisorCeroException(); } return a / b; Aquí si estamos devolviendo una excepción que le permite al módulo invocante determinar cual es el problema específico y poder manejarlo.

Definición de Excepciones propias public class DivisorCeroException extends Exception{ public DivisorCeroException(String message) { super(message); } public DivisorCeroException() { @Override public String getMessage() { if (super.getMessage()==null) return "Divisor igual a cero"; return super.getMessage();

Definición de Excepciones propias Lo que permite a la clase DivisorCeroException que se caracterice como una excepción es que hereda de la clase Exception. Posee dos constructores, uno sin parámetros y el otro recibe el mensaje que va a devolver el objeto cuando se invoque el método getMessage sobre el mismo. También, estos dos constructores invocan a los respectivos constructores de la superclase Exception. Es una buena práctica finalizar el nombre de las clases de excepciones con la palabra Exception descendientes de la familia de Exception. De manera similar, las clases descendientes de la familia de Error, deberían terminar con la palabra Error.