Módulo 11: MANEJO DE EXCEPCIONES 11-1

Módulo 11: MANEJO DE EXCEPCIONES 11-1

SUMARIO MANEJO DE EXCEPCIONES 1 SUMARIO 2 11.1. INTRODUCCIÓN 3 11.1.1. Tratamiento de Errores vs. Tratamiento de Excepciones 3 11.1.2. Qué ocurre cuando se produce una excepción? 4 11.2. JERARQUÍA DE EXCEPCIONES 5 11.3. LANZAMIENTO DE EXCEPCIONES DE FORMA EXPLÍCITA 6 11.4. TRATAMIENTO DE EXCEPCIONES 7 11.5. EXCEPCIONES Y HERENCIA 11 11.6. UN EJEMPLO APLICADO 12 11.7. EJERCICIOS PROPUESTOS 12 11.8. PREGUNTAS 13 C Perfecto del Amo 11-2

11.1. INTRODUCCIÓN Una excepción es un evento excepcional que ocurre durante la ejecución de un programa, y que interrumpe el flujo normal de las sentencias. Dentro de un programa son muchos los tipos de errores que pueden conducir a provocar una excepción, desde un desbordamiento de memoria o un disco duro estropeado hasta un disquete protegido contra escritura, un intento de dividir por cero o intentar acceder a un array fuera de sus límites. Sin embargo, si repasamos atentamente la definición anterior veremos que las excepciones se dan durante la ejecución del programa. Por tanto vemos ya que, a diferencia de lo que hemos venido haciendo hasta el momento donde corregíamos errores que se detectaban en tiempo de compilación, mediante el manejo y tratamiento de excepciones pasamos a trabajar en otro plano: el plano de ejecución de nuestros programas. Programas que, necesariamente, habrán superado la fase de compilación y estarán por tanto ya libres de este tipo de errores. 11.1.1. Tratamiento de Errores vs. Tratamiento de Excepciones Ahora que conocemos los fundamentos de la programación en Java y por ende los elementos comunes a cualquier lenguaje de programación y hemos experimentado con pequeñas aplicaciones deberíamos ser conscientes de que el trabajo del programador no finaliza desde luego con la compilación del código fuente. Un código aparentemente libre de errores está expuesto a errores indetectables hasta el momento de la ejecución. Lo ideal sería haber sido capaces de atar todos los cabos llegados a este punto, pero esto resulta cuanto menos imposible. Otros lenguajes de programación, como C por ejemplo, fundamentan el tratamiento de errores en tiempo de ejecución en la recolección a lo largo del desarrollo del programa de los códigos de retorno de las llamadas a los métodos o rutinas empleados. Estos valores son contrastados con los valores esperados y en base a los resultados de la comparación es posible tomar consciencia de qué ha fallado y decidir entonces qué acciones tomar. Esta aproximación al tratamiento de errores en tiempo de ejecución presenta dos claros inconvenientes: 1) Implica un trabajo muy minucioso, a la vez que tedioso, para el programador que tiende -tendemos- a pasar por alto demasiadas condiciones de error fruto de un exceso de confianza. 2) Por otra parte si, pese a todo, no caemos en el mencionado error nuestro código se convertirá en ilegible pues el código correspondiente a las comprobaciones de condiciones de error dificultará la lectura del código útil. Y, sin embargo, debemos detectar y tratar de corregir los errores que surjan en tiempo de ejecución. La solución adoptada en Java pasa por separar la detección de errores de su tratamiento. De esta manera, ante la aparición de un error se detendrá la ejecución normal del programa y se buscará la zona de código preparada para tratar la incidencia en cuestión, el manejador de excepciones o Exception handler. Como veremos más adelante, para dar con el manejador adecuado se realizará una búsqueda jerarquizada de tal forma que si el contexto actual de funcionamiento en un momento dado no C Perfecto del Amo 11-3

dispone de la información o capacidad necesaria para tratar una determinada excepción, la responsabilidad recaíga en un contexto superior continuando este proceso hasta localizar el manejador o con la finalización del programa al no estar éste preparado para el tratamiento de la excepción producida. Una de las más claras ventajas de esta estrategia es que el código de manejo de errores prácticamente desaparece: No necesitamos ya tratar el error allí donde surja por lo que el código se descarga: Sólo se escribe el tratamiento para cada uno de los posibles errores una vez, en el gestor de excepciones, con independencia del número de puntos a lo largo del programa en los que pueda aparecer. La lectura, escritura y DEPURACIÓN de los programas es resulta MUCHO MAS SENCILLA empleando el tratamiento de excepciones. 11.1.2. Qué ocurre cuando se produce una excepción? En Java, cuando se lanza una excepcion, la JVM (la máquina virtual de java) crea un objeto de la clase Exception y con ello detiene la ejecución normal del programa. La ejecución del programa se ha quedado en un estado de error, y si no se tratara de alguna forma, podría llegar a interrumpirse la ejecución del programa. Un método se dice que es capaz de tratar y captura una excepción si ha previsto con anterioridad el error que se ha producido y prevé también las operaciones a realizar para recuperar el programa del estado de error en el que ha quedado. En el momento en que es lanzada una excepción, la JVM recorre la cadena de llamadas de métodos en busca de alguno que sea capaz de tratar la clase de excepción lanzada. Es decir, comienza examinando el método donde se ha producido la excepción; si este método no es capaz de tratarla, examina el método desde el que se realizó la llamada al método donde se produjo la excepción y así sucesivamente hasta llegar al último de ellos (que en el caso de programas standalone, será el método main). En caso de que ninguno de los métodos sea capaz de tratar la excepción, la JVM muestra un mensaje de error y el programa termina. Ejemplo: int i=5, j=0; int k=i/j; class Excepcion public static void main(string argumentos[]) // División por cero /* En pantalla: java.lang.arithmeticexception: / by zero at Excepcion.main(Excepcion.java:6) Exception in thread "main" Process Exit */ Lo que ha ocurrido es que la JVM ha detectado una condición de error y ha creado un objeto de la clase java.lang.arithmeticexception. Como el método donde se ha producido la excepción, el main, no es capaz de tratarla, es tratada directamente por la JVM, mostrando el mensaje de error y dando por finalizada la ejecución del programa. C Perfecto del Amo 11-4

11.2. JERARQUÍA DE EXCEPCIONES Las excepciones son objetos pertenecientes a la clase Throwable o alguna de sus derivadas. La clase Throwable deriva directamente de Object. Así, Java tiene una jerarquía de clases de excepciones para cada tipo de excepción que se pueda producir. Esas clases se encuentran en el paquete java.lang, y la jerarquía que conforman se ve en la siguiente figura: Object Throwable Error Exception RuntimeException Entre las excepciones que derivan directamente de Exception, están ClassNotFoundException, DataFormatException, IOException, etc. Entre las excepciones derivadas de RuntimeException, están ArithmeticException, IllegalArgumentException, IndexOutOfBoundsException, NullPointerException, etc. Todas las excepciones, por derivar de alguna forma de Throwable, tienen métodos heredados de ella: getmessage() tostring(): Este método está definido por primera vez en la clase Object, pero se redefine en Throwable. printstacktrace fillinstacktrace Las excepciones derivadas de Error, son para el uso propio de la JVM, y no se suelen usar a la hora de programar. Las excepciones derivadas de Exception las que se usan al programar, y se pueden dividir en: Las excepciones comprobables (o explícitas) son repasadas por el compilador Java durante el proceso de compilación, de forma que si no se indica que son lanzadas de forma explícita o no se tratan, se generará un mensaje de error: clase Exception y las que derivadan directamente de ella. Las excepciones no comprobables (o implícitas) son la clase RuntimeException y sus subclases (junto con la clase Error y sus subclases). No hace falta especificar que se van a lanzar o tratarlas, para que el compilador no de error. C Perfecto del Amo 11-5

El programador puede podemos- también definir nuevas excepciones a través de subclases de las excepciones anteriores. Así se crean nuevas excepciones no contempladas por Java y que se ajustan de forma específica a las necesidades de nuestro programa. Las excepciones se definen como cualquier otra clase en Java; la única condición es que para que una clase efectivamente sea una excepción, tiene necesariamente que derivar de Throwable, directa o indirectamente (si lo hace a través de la subclase Exception). 11.3. LANZAMIENTO DE EXCEPCIONES DE FORMA EXPLÍCITA Un método es capaz de lanzar excepciones indicándolo de forma explícita. Este lanzamiento explícito, se realiza mediante la instrucción throw. Cuando la excepción que se lanza es implícita (derivada de RuntimeException), no es necesario indicar nada en la declaración del método. Sin embargo, como decimos si la excepción es explícita (derivada de Exception), es necesario indicar en la declaración del método, que se va a producir el lanzamiento de la misma, mediante la palabra reservada throws. Ejemplo: class LanzaExcepcion public static void main(string argumentos[]) throws Exception int i=1, j=2; if (i/j<1) throw new Exception(); //Lanza la excepción else System.out.println(i/j); En pantalla: java.lang.exception at LanzaExcepcion.main(LanzaExcepcion.java:7) Exception in thread "main" Process Exit java.lang.exception es la clase del objeto excepción lanzado. LanzaExcepcion.main es el nombre del método que ha lanzado la excepción. LanzaExcepcion.java es el nombre del fichero fuente en el que se ha producido el lanzamiento de la excepción, y 7 es la línea en del fichero fuente en el que se ha lanzado la excepción. Tal como se ve en el ejemplo, como la excepción Exception es de tipo comprobable, es necesario indicar en la declaración del método que se va a lanzar una excepción de esa clase, utilizando la cláusula throws. Para lanzar la excepción, es necesario crear un objeto de la clase de la excepción que se va a lanzar (en este caso: Exception) y lanzarlo mediante la instrucción throw. Para crear el objeto excepción, se usa como sabemos el operador new. Al producirse el lanzamiento de la excepción, se deja de ejecutar el método y se devuelve el control al método que lo invocó. Si ese método no trata la excepción que le ha llegado, también deja de ejecutarse y pasa el control a su vez al método que lo llamó/invocó a él. Así, hasta llegar al origen en la cadena de llamadas de métodos, que en el caso de programas ejecutables standalone será el método main. Si ese método main no trata la excepción, se produce un error y se deja de ejecutar el programa. Eso es precisamente lo que ha ocurrido en el ejemplo anterior. C Perfecto del Amo 11-6

Ejemplo: (6): Recoge la excepción pero no la trata ERROR! Terminación anormal del programa (1): Llama a (6): Manda excepción a (5): Recoge la excepción pero no la trata (2): Llama a (4): Manda excepción a (3): Lanza excepción pero no la trata 11.4. TRATAMIENTO DE EXCEPCIONES En Java, se pueden tratar las excepciones previstas por el programador utilizando unos mecanismos específicos, los manejadores de excepciones -exception handlers-, que se estructuran en tres bloques: El bloque try El bloque catch El bloque finally Un manejador de excepciones es una porción de código que se va a encargar de tratar las posibles excepciones que se puedan generar. Tratando las excepciones con un manejador, se evita que el lanzamiento automático de la excepción a través de la cadena de métodos llamantes, evitando que se llegue hasta el comienzo de la misma, y se interrumpa la ejecución del programa. La sintaxis general de un manejador es la siguiente: try Cuerpo del try catch (TipoExcepción1 nombrevariable) Cuerpo del catch catch (TipoExcepción2 nombrevariable) finally Cuerpo del finally Tal como se ve en la sintaxis general, un manejador de excepciones siempre va a tener un bloque try, un bloque catch asociado por lo menos, y puede o no tener un bloque finally. Lo primero que hay que hacer para que un método sea capaz de tratar una excepción, es encerrar las instrucciones susceptibles de generarla, en un bloque try. C Perfecto del Amo 11-7

En el momento en que se produzca la excepción, se abandona el bloque try y, por lo tanto, las instrucciones internas al try que sigan al punto donde se produjo la excepción, no serán ejecutadas. ATENCION: Cada bloque try debe tener asociado por lo menos un bloque catch. Cada uno de los bloques catch asociados será capaz de tratar un tipo u otro de excepción (no puede haber dos bloques catch que traten el mismo tipo de excepción). Y, para indicar el tipo de excepción que es capaz de tratar un bloque catch, se declara un objeto cuya clase es la clase de la excepción que se desea tratar (o una de sus superclases). Por ejemplo: class ExcepcionTratada public static void main(string argumentos[]) int i=5, j=0; try int k=i/j; //-1- System.out.println("Esto no se va a ejecutar."); catch (ArithmeticException ex) System.out.println("Ha intentado dividir por cero y conseguir un entero"); System.out.println("Fin del programa"); /* En pantalla: Ha intentado dividir por cero y conseguir un entero Fin del programa */ Cuando la JVM llega al punto 1, se da cuenta de que se está intentando dividir por cero y guardarlo en un entero. Como eso no es posible, la JVM genera un objeto de la clase ArithmeticException, que es la adecuada para tratar este tipo de excepciones. Al producirse la excepción dentro de un bloque try, la ejecución del programa se pasa al primer bloque catch. Si la clase de la excepción (en este caso, ArithmeticException) se corresponde con la clase o alguna subclase de la clase declarada en el bloque catch, se ejecuta el bloque de instrucciones contenidas en el catch y a continuación se pasa el control del programa a la primera instrucción tras los bloques try-catch. Como puede verse, también se podría haber utilizado en la declaración del bloque catch, una superclase de la clase ArithmeticException. Pero aunque esto no de errores en la compilación, no es del todo correcto. Hay que atrapar en los bloques catch, clases de excepciones que se acerquen lo más posible a las excepciones que se van a lanzar en el bloque try, ya que estas tendrán métodos que traten mejor las características concretas de su excepción. También hay que tener cuidado con el orden en el que se escriben los bloques catch. JVM va mirando la excepción que atrapa cada uno de ellos, en el orden en el que están escritos en el programa, por lo que se ejecutará el primer bloque catch que atrape una C Perfecto del Amo 11-8

excepción de misma clase. Si la clase que atrapa un catch es jerárquicamente superior a la clase de la excepción lanzada, y ambas están relacionadas mediante herencias, ese bloque catch se ejecutará. Por eso, para programar bien los bloques catch, hay que escribir primero los que atrapan clases de excepciones más concretas, e ir subiendo después en la jerarquía de excepciones. Ejemplo: class ExcepcionTratada public static void main(string argumentos[]) int i=5, j=0; try int k=i/j; //Sit.1 System.out.println("Esto no se va a ejecutar."); catch (Exception ex) System.out.println("Ha ocurrido una excepción"); catch (ArithmeticException ex) System.out.println("Ha intentado dividir por cero"); System.out.println("Fin del programa"); /* En pantalla: ExcepcionTratada.java:15: exception java.lang.arithmeticexception has already been caught catch (ArithmeticException ex) ^ 1 error */ /* En el caso de que fruto de la compilación no se produjeran errores la única salida posible sería: Ha ocurrido una excepción Fin del programa */ Como la clase Exception es jerárquicamente superior a la clase ArithmeticException, y su bloque catch es anterior, la JVM ejecuta el bloque catch de Exception e ignora el resto de bloques catch, aunque realmente las excepciones que traten se acerquen más a la excepción lanzada. Este código por lo tanto, no sería correcto. La clase ArithmeticException tendrá métodos más concretos que podríamos usar dentro de su bloque catch para poder manejar la excepción, pero en este caso, si se mantiene el orden de escritura de los bloques catch como están, no serviría de nada, ya que el que se ejecutaría sería siempre el catch del Exception. Después de los bloques catch puede haber un bloque finally, si es que existe. El bloque finally se utiliza para ejecutar un bloque de instrucciones sea cual sea la excepción que se produzca. Este bloque se ejecutará en cualquier caso, incluso si no se produce ninguna excepción, o después de haber sido atrapada por algún match, o la excepción producida no se ha podido atrapar en ninguno de los bloques catch previstos. En este último caso, si no hubiera ningún bloque finally, la excepción se mandaría al método llamante, pasándole también el control de flujo. Sirve para no tener que repetir código en el bloque try y en los bloques catch. C Perfecto del Amo 11-9

Ejemplo: class MiExcepcion extends Exception //Nota 1 int numero; MiExcepcion(int k) //Nota 2 numero=k; void mensaje() System.out.println("Ha habido una excepción de las mías. El n "+numero); class LanzaExcepcion2 static void metodo2(int k2) throws MiExcepcion //Nota 3 if(k2<1) throw new MiExcepcion(k2); //Nota 4 System.out.println("Esto ya no se ejecuta"); static void metodo1(int k1) throws MiExcepcion //Nota 5 metodo2(k1); public static void main(string args[]) int i=1,j=2; int k=i/j; try metodo1(k); //Nota 6 System.out.println("Esto ya no se ejecuta"); catch(miexcepcion me) //Nota 7 me.mensaje(); //Nota 8 finally System.out.println("Esto se ejecuta siempre"); //Nota 9 //Nota 10 System.out.println("Esto se ejecuta si la excepción ha sido tratada, o no se ha producido"); /* En pantalla: Ha habido una excepción de las mías. El número es: 0 Esto se ejecuta siempre Esto se ejecuta si la excepción ha sido tratada o no se ha producido */ Notas: 1: Declaración de una clase propia, que va a ser una excepción derivada de Exception. 2: Constructor de la excepción, al que se le pasa un int como parámetro. C Perfecto del Amo 11-10

3: El método es static porque será llamado por otro método que también lo es. Lanza una excepción derivada directamente de Exception, por lo que hay que indicarlo. 4: Lanzamiento de la excepción. El objeto MiExcepción se crea mediante un constructor que no es el constructor por defecto. 5: El método es static porque será llamado por otro método que también lo es. Puede recibir una excepción que no trata, por lo que la va a relanzar. Como esa excepción es derivada directamente de Exception, hay que indicar que la puede lanzar. 6: Se produce la excepción dentro del bloque try. Lo que haya a partir de esta línea dentro del bloque try, no se va a ejecutar. 7: Atrapa excepciones de clase MiExcepcion y derivadas. 8: Llama al método mensaje() del objeto excepción atrapado. 9: El bloque finally se ejecuta siempre, tanto si de ha producido y atrapado una excepción como si no. 10: Lo que queda fuera del manejador se ejecuta si la excepción ha sido tratada o no se ha producido. 11.5. EXCEPCIONES Y HERENCIA Como ya vimos en el tema 7 que trataba la herencia en Java, cuando una clase deriva de otra, hereda todos los atributos y los métodos de su superclase. Si alguno de los métodos heredados lanza excepciones en la superclase, también las lanzará en la clase derivada, con la particularidad de que además, sólo podrá lanzar las mismas excepciones que en la superclase. Ejemplo: class A void funcion() throws EOFException class B extends A void funcion() throws EOFException, FileNotFoundException //ERROR! Los métodos heredados en una clase derivada, pueden lanzar menos excepciones que en la definición original, pero nunca pueden lanzar excepciones nuevas que no se lanzaran en la definición original. A la vista de esto un método puede indicar en su declaración que lanza excepciones que realmente no lanza. En una clase que va a ser superclase de otras, se puede indicar en sus métodos que estos lanzan excepciones que realmente no se llegan a producir, al menos en la definición original, con miras a que en las redefiniciones de las subclases derivadas sí se puedan lanzar. En los constructores, al no heredarse, puede lanzarze todas las excepciones que se quiera. C Perfecto del Amo 11-11

11.6. UN EJEMPLO APLICADO import java.io.*; class LeerTeclado static BufferedReader inp = new BufferedReader(new InputStreamReader(System.in)); public static String leerlinea() String s = ""; try s=inp.readline(); catch (java.io.ioexception e) return s; // Esto es JDK 1.1y1.2. Con JDK 1.0: // char c; // try // while( (c = (char)system.in.read())!= '\n') // s += c; // // catch (java.io.ioexception e) public static String leerlinea( String mens ) // con prompt System.out.print( mens ); return leerlinea(); /* leerdoble() Devuelve NaN en caso de error */ public static double leerdoble() String s = leerlinea(); double d; try d = Double.valueOf( s ).doublevalue(); catch (java.lang.numberformatexception e) d = Double.NaN; return d; public static double leerdoble( String mens ) // con prompt System.out.print( mens ); return leerdoble(); public static void main (String[] a) double d1 = leerdoble( "Introduce un número real: " ); double d2 = leerdoble( "Introduce otro: " ); System.out.println( "La suma de ambos es: " + (d1+d2) ); 11.7. EJERCICIOS PROPUESTOS 1.- Diseña e implementa una clase Fraccion que permite crear fracciones (numerador y denominador enteros), con métodos para sumar, restar, multiplicar y dividirlas. Crea una excepción FraccionException que se lance siempre que en una operación de fracción se produzca un error, a saber: Creación de una fracción con denominador cero. División de una fracción entre otra con numerador cero. Cualquier operación que incluya una fracción con denominador cero. C Perfecto del Amo 11-12

Haz que cada operación crítica lance esta excepción si se produce, con un mensaje indicativo del tipo de error (mensaje incluido en la excepción, no salida a pantalla!). Probar la clase. 11.8. PREGUNTAS Os propongo tratar de responde a las siguientes preguntas para que evalueis el grado de asimilación de los conceptor tratados en este tema. Suponiendo que la excepción con la que se está trabajando se trata de una excepción Explícita: 1. Suponer que en un bloque try, después de invocar al método que lanza la excepción, se pone otra sentencia, por ejemplo un mensaje a pantalla "Sentencia después de capturar una excepción". Si como resultado de ejecutar el método se lanza la excepción y se captura: Sale el mensaje por pantalla? 2. Y, si no se captura y se ignora la excepción, Sale el mensaje por pantalla? 3. Desde una método X se llama a un método Y que lanza una excepción Si se ignora y no se pone en la declaración del método X, cuál es el mensaje de error del compilador? 4. Sucede lo mismo si quien llama al método que lanza la excepción es el método 'main'? 5. Hacer la siguiente secuencia de llamadas: Método f3: Llama al método f2 y saca un mensaje por pantalla "Soy el método f3" Método f2: Llama al método f1 con el valor 2 como parámetro, vuelve a llamar al método f1 con el valor 1 como parámetro y saca un mensaje por pantalla "Soy el método f2" Método f1: Lanza una excepción (Parametro1Exception) si el valor del parámetro que recibe es 1, en caso contrario saca un mensaje "Soy el método f1". La excepción hay que definirla. a.- Qué pasa si nadie captura la excepción? b.- Modificar el programa para que f3 capture la excepción c.- Modificar el programa para que f2 capture la excepción d.- Indicar como conclusión: Se ejecuta el código que está después del bloque catch cuando se ha producido la excepción? Se ejecuta el código que viene después de la invocación al método que produce la excepción? Qué pasa si tanto el método f2 como el método f3 capturan la excepción? 6. Con el ejemplo anterior, comprobar mediante ejemplos que el bloque finally se ejecuta: a.- Si todo va bien y no se lanza la excepción b.- Si se lanza la excepción y se captura c.- Si se lanza la excepción pero no se captura 7. Se puede poner un bloque finally sin un bloque try? 8. Se puede poner un bloque finally sin un bloque catch? C Perfecto del Amo 11-13