Manejo de Excepciones

Transcripción

1 Manejo de Excepciones H. Tejeda Abril 2016 Índice 1. Introducción 1 2. Intentar código y capturar excepciones 5 3. Lanzar y atrapar excepciones múltiples Bloque finally Ventajas del manejo de excepción Especificar excepciones que un método puede lanzar Traza de excepciones en la pila de llamadas Creación de clases Exception propias Uso de afirmaciones Introducción Una excepción es una condición inesperada o error. Los programas que se escriben pueden generar varios tipos de excepciones potenciales: Podría emitir un comando para leer un archivo de un disco, pero el archivo no existe. Podría intentar escribir datos a un disco, pero el disco está lleno o no formateado. Podría pedir entrada al usuario, pero el usuario ingresa un tipo de dato no válido. 1

2 Podría intentar acceder un arreglo con un subíndice que no es válido. Estos errores son llamados excepciones porque no son ocurrencias usuales. El manejo de excepciones es el nombre para las técnicas orientadas al objeto que manejan tales errores. Excepciones no planeadas que ocurren durante la ejecución del programa son también llamadas excepciones en tiempo de ejecución, en contraste con errores de sintaxis que son descubiertos durante la compilación del programa. Java incluye dos clases básicas de errores: Error y Exception. Ambas clases descienden de la clase Throwable, como se muestra enseguida. Como todas las otras clases en Java, Error y Exception originalmente descienden de Object. java.lang.object +--java.lang.throwable +--java.lang.exception +--java.io.ioexception +--java.lang.runtimeexception +--java.lang.arithmeticexception +--java.lang.indexoutofboundsexception +--java.lang.arrayindexoutofboundsexception +--java.util.nosuchelementexception +--java.util.inputmismatchexception +--Otras Otras java.lang.error +--java.lang.virtualmachineerror +--java.lang.outofmemoryerror +--java.lang.internalerror +--Otras Otras... 2

3 La clase Error representa los errores más serios de los cuales el programa usualmente no se pueden recuperar. Podría haber memoria insuficiente para ejecutar un programa. Usualmente, no se usan o implementan objetos Error en el programa. Un programa no se puede recuperar de las condiciones Error por su propia cuenta. La clase Exception comprende errores menos serios que representan condiciones no usuales que surgen mientras un programa se ejecuta y del cual el programa se puede recuperar. Estos errores se dan al usar un subíndice de arreglo no válido o realizando ciertas operaciones aritméticas ilegales. Java muestra un mensaje Exception cuando el código del programa podría haber prevenido un error. La aplicación Division, código 1, contiene en el método main() tres declaraciones de enteros, peticiones al usuario de valores para dos variables, y el cálculo del valor del tercer entero haciendo la división de los valores dados. 1 import java. u t i l. Scanner ; 2 public class D i v i s i o n { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 7 numerador = entrada. nextint ( ) ; 8 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 9 denominador = entrada. nextint ( ) ; 10 r e s u l t a d o = numerador / denominador ; 11 System. out. p r i n t l n ( numerador + / + denominador + 12 = + r e s u l t a d o ) ; Código 1: La clase Division. Como se muestra en la siguiente salida, al ejecutar la aplicación Division y habiendo el usuario ingresado un cero para el denominador, se genera un mensaje de excepción. Java no permite división entera por cero, pero la división flotante por cero es permitida, dando el resultado Infinity. Los programadores dicen que el programa experimentó un choque, para indicar que el programa terminó prematuramente con un error. El término choque quizás evolucionó del error de hardware que ocurre cuando una cabeza de lectura/escritura abruptamente hace contacto con un disco duro, para incluir los errores de software que causan la falla del programa. $ java Division Ingresar el numerador >> 3 Ingresar el denominador >> 0 Exception in thread "main" java.lang.arithmeticexception: / by zero at Division.main(Division.java:10) De la salida de la aplicación, mostrada previamente, la Exception es una java.lang.arithmetic- Exception la cual es una de muchas subclases de Exception. Java conoce más de 75 categorías de Exception con nombres raros como ActivationException, AlreadyBoundException, AWTException, CloneNotSupportedException, PropertyVetoException, y UnsupportedFlavorException. 3

4 Además del tipo de Exception que se muestra en la ejecución se muestra alguna información del error ( / by zero ), el método que genero el error(division.main), y el archivo y número de línea para el error(division.java, línea 10). En la siguiente salida se muestran dos ejecuciones más de la aplicación Division. En cada ejecución, el usuario ha metido datos no enteros para el denominador, primero una cadena de carateres, y luego un valor de punto flotante. De los mensajes de error se ve que en ambos casos la Exception es una InputMismatchException. La última línea del mensaje indica que el problema ocurrió en la línea 9 de la aplicación, y el mensaje de error que le antecede muestra que el problema ocurrió dentro de la llamada a nextint(). Como el usuario no ingreso un entero, el método nextint() falló. Por supuesto que no se quiere modificar el método nextint() que reside en la clase Scanner, se prefiere volver a ejecutar el programa y meter un entero, o modificar el programa para que estos errores no puedan ocurrir. $ java Division Ingresar el numerador >> 12 Ingresar el denominador >> tres Exception in thread "main" java.util.inputmismatchexception at java.util.scanner.throwfor(scanner.java:909) at java.util.scanner.next(scanner.java:1530) at java.util.scanner.nextint(scanner.java:2160) at java.util.scanner.nextint(scanner.java:2119) at Division.main(Division.java:9) $ java Division Ingresar el numerador >> 12 Ingresar el denominador >> 3.0 Exception in thread "main" java.util.inputmismatchexception at java.util.scanner.throwfor(scanner.java:909) at java.util.scanner.next(scanner.java:1530) at java.util.scanner.nextint(scanner.java:2160) at java.util.scanner.nextint(scanner.java:2119) at Division.main(Division.java:9) La lista de mensajes de error que se muestran en los intentos de ejecución mostrados previamente es llamada una lista del historial de seguimiento de la pila, o un seguimiento de la pila. La lista muestra cada método que fue llamado conforme el programa se ejecutaba. Sólo porque una excepción ocurra, no es obligatorio manejarla. Se puede dejar el código sin modificación pero, la terminación del programa es abrupta. Posiblemente algún usuario podría estar molesto si el programa termina abruptamente. Sin embargo, si el programa es usado para tareas de misión crítica tales como el control del tráfico aéreo, o para monitorear los signos vitales de un paciente en una cirugía, una conclusión abrupta podría ser desastrosa. Las técnicas de manejo de error orientadas al objeto dan soluciones elegantes y seguras para errores. Se pueden escribir programas sin usar técnicas de manejo de excepciones. Posiblemente la solución de manejo de errores más común ha sido el uso de una decisión para evitar un error. Por ejemplo, se puede cambiar el método main() de la clase Division para evitar dividir por cero agregando la 4

5 decisión como se muestra en la aplicación DivisionIf, código 2. 1 import java. u t i l. Scanner ; 2 public class D i v i s i o n I f { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 7 numerador = entrada. nextint ( ) ; 8 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 9 denominador = entrada. nextint ( ) ; 10 i f ( denominador == 0) 11 System. out. p r i n t l n ( No se puede d i v i d i r por 0 ) ; 12 else { 13 r e s u l t a d o = numerador / denominador ; 14 System. out. p r i n t l n ( numerador + / + denominador + 15 = + r e s u l t a d o ) ; Código 2: Aplicación DivisionIf. La aplicación DivisionIf muestra un mensaje al usuario cuando cero es ingresado para el valor del denominador, pero no se puede recuperar cuando un dato no entero, como una cadena o un valor punto flotante, es ingresado. Los programas que pueden manejar excepciones apropiadamente se dice que son más tolerantes a las fallas y robustos. Las aplicaciones tolerantes a las fallas son diseñadas para que puedan continuar operando, posiblemente a un nivel reducido, cuando alguna parte del sistema falla. La robustez representa el grado en el cual un sistema es resistente al uso, manteniendo el funcionamiento correcto. Es importante entender las técnicas de manejo de excepciones porque los métodod incorporados en Java lanzarán excepciones a los programas. 2. Intentar código y capturar excepciones En la terminología orientada al objeto, se intenta (try) un procedimiento que podría causar un error. Un método que detecta una condición de error lanza (throws) una excepción, y el código de bloque que procesa el error atrapa (catch) la excepción. Cuando se crea un segmento de código en el cual algo podría ir mal, se coloca el código en un bloque try, el cual es un bloque de código que se intenta ejecutar mientras se reconoce que una excepción podría ocurrir. Un bloque try consiste de los siguientes elementos: La palabra reservada try. Una llave de apertura. Sentencia ejecutables, incluyendo algunas que podrían causar excepciones. 5

6 Una llave de cierre. Para manejar una excepción lanzada, se pueden codificar uno o más bloques catch siguiendo inmediatamente al bloque try. Un bloque catch es un segmento de código que puede manejar una excepción que podría ser lanzada por el bloque try que le precede. La excepción podría ser una que es lanzada automáticamente, o se podría explícitamente escribir una sentencia throw. Una sentencia throw es una que manda un objeto Exception fuera de un bloque o un método para que pueda ser manejada donde sea. Una Exception lanzada puede ser capturada por un bloque catch. Cada bloque catch puede atrapar un tipo de excepción, es decir, un objeto que es del tipo Exception o de sus clases hijas. Se crea un bloque catch poniendo los siguientes elementos: La palabra reservada catch. Un paréntesis de apertura. Un tipo o subtipo Exception. Un identificador para una instancia del tipo Exception. Un paréntesis de cierre. Una llave de apertura. Las sentencias que toman la acción que se quiere usar para manejar la condición de error. Una llave de cierre. Se muestra enseguida el formato general de un método que incluye un par try...catch. Un bloque catch se parece a un método llamado catch() que toma un argumento que es algún tipo de Exception. Sin embargo, no es un método; no tiene tipo que se devuelve, y no se puede llamar directamente. Algunos programadores se refieren a un bloque catch como una cláusula catch. tipodevuelto nombremétodo(parámetros opcionales) { // sentencias opcionales previas al código que se intentará try { // sentencias que podrían generar una excepción catch (Exception algunaexcepción) { // acciones que se harán si la excepción ocurre // sentencias opcionales que ocurren después del try, // ya sea que el bloque catch se ejecute o no Cuadro 1: Formato try...catch en un método. En el formato, algunaexcepción representa un objeto de la clase Exception o alguna de sus subclases. Si una excepción ocurre durante la ejecución del bloque try, las sentencias en el bloque 6

7 catch se ejecutan. Si no ocurre una excepción dentro del bloque try, el bloque catch no se ejecuta. De cualquier forma, las sentencias que siguen el bloque catch se ejecutan normalmente. La aplicación DivisionPorCeroAtrapada, código 3, mejora la clase Division. El método main() contiene un bloque try con código que intenta dividir. Cuando una división entera ilegal es intentada, una ArithmeticException es automáticamente creada y el bloque catch es ejecutado. 1 import java. u t i l. Scanner ; 2 public class DivisionPorCeroAtrapada { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 7 numerador = entrada. nextint ( ) ; 8 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 9 denominador = entrada. nextint ( ) ; 10 try { 11 r e s u l t a d o = numerador / denominador ; 12 System. out. p r i n t l n ( numerador + / + denominador + 13 = + r e s u l t a d o ) ; catch ( ArithmeticException e r r o r ) { 16 System. out. p r i n t l n ( I n tento de d i v i d i r por 0 ) ; Código 3: Aplicación DivisionPorCeroAtrapada. Enseguida se muestra la salida de dos ejecuciones de la aplicación, una con una excepción generada y una sin excepción. $ java DivisionPorCeroAtrapada Ingresar el numerador >> 20 Ingresar el denominador >> 5 20 / 5 = 4 $ java DivisionPorCeroAtrapada Ingresar el numerador >> 20 Ingresar el denominador >> 0 Intento de dividir por 0 Nota. En la aplicación DivisionPorCeroCapturada, las operaciones lanzar y atrapar están en el mismo método. Después se revisará que los lanzamientos y su correspondiente bloque de captura frecuentemente están en métodos separados. Nota. Si se quiere mandar mensajes de error a una localidad diferente a la salida normal, se puede usar System.err en vez de System.out. Por ejemplo, si una aplicación escribe un reporte a un archivo de disco específico, se podría querer que los errores se escriben en una localidad diferente, como en otro disco o a la pantalla. 7

8 Cualquier ArithmeticException generada dentro del bloque try podría ser atrapada por el bloque catch en el método, para la aplicación DivisionPorCeroAtrapada. Se puede usar el método de instancia getmessage() calificado con la excepción atrapada, que ArithmeticException hereda de la clase Throwable, en vez de poner su propio mensaje. En la aplicación DivisionPorCeroAtrapada2, código 4, usa el método getmessage(), línea 16, para generar el mensaje que viene con el argumento atrapado ArithmeticException para el bloque catch. Al ejecutar esta aplicación con un denominador que sea cero, se muestra el mensaje / by zero. 1 import java. u t i l. Scanner ; 2 public class DivisionPorCeroAtrapada { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 7 numerador = entrada. nextint ( ) ; 8 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 9 denominador = entrada. nextint ( ) ; 10 try { 11 r e s u l t a d o = numerador / denominador ; 12 System. out. p r i n t l n ( numerador + / + denominador + 13 = + r e s u l t a d o ) ; catch ( ArithmeticException e r r o r ) { 16 System. out. p r i n t l n ( I n tento de d i v i d i r por 0 ) ; Código 4: Aplicacion DivisionPorCeroAtrapada2. El mensaje / by zero ya había sido visto previamente, y fue cuando el programa, Division, no tenía manejo de excepciones. Por supuesto que se quiere hacer más que mostrar un mensaje de error en el bloque catch; después de todo, Java lo hacía sin requerir escribir código para atrapar cualquier excepción. Se podría querer agregar código para corregir el error; tal código podría forzar la aritmética al dividir por uno en vez de cero. Enseguida se muestra un código try...catch que realiza lo comentado. Después del bloque catch, la aplicación podría continuar con la garantía que resultado tiene un valor válido, aún si la división funcionó en el bloque try y el bloque catch no se ejecuto, o el bloque catch arregla el error. try { resultado = numerador / denominador; catch (ArithmeticException error) { resultado = numerador / 1; // el programa continúa aquí; resultado está garantizado // para tener un valor valido 8

9 Uso de un bloque try para hacer programa infalibles Uno de los usos más comunes del bloque try es para esquivar errores de entrada de datos del usuario. Como cuando el usuario en la aplicación Division ingresa un carácter o un número de punto flotante en respuesta a la llamada del método nextint() y hace que la aplicación choque. Usando un bloque try se puede permitir manejar excepciones potenciales de conversión de datos causadas por usuarios distraidos. Las llamadas a nextint() o nextdouble() se ponen en el bloque try y luego se maneja cualquier error generado. Después de cualquier llamada al método next(), nextint(), o nextdouble() se agrega una llamada a nextline() para leer la tecla Intro remanente en el búfer de entrada, antes de llamadas subsecuentes nextline(). Cuando se intenta convertir a dato numérico en un bloque try y es seguido por otro intento de conversión, se debe tener en cuenta los caracteres remanentes dejados en el búfer de entrada. En la aplicación IngresoEnteros, código 5, se aceptan y se muestran un arreglo de seis enteros. 1 import java. u t i l. Scanner ; 2 public class I n g r e s o E n t e r o s { 3 public static void main ( S t r i n g [ ] args ) { 4 int [ ] listanumeros = {0, 0, 0, 0, 0, 0 ; 5 Scanner entrada = new Scanner ( System. in ) ; 6 for ( int x = 0 ; x < listanumeros. length ; ++x ) { 7 try{ 8 System. out. p r i n t ( I n g r e s a un entero >> ) ; 9 listanumeros [ x ] = entrada. nextint ( ) ; catch ( Exception e ) { 12 System. out. p r i n t l n ( Ocurrió una e x c e p c i ón ) ; // entrada. nextline ( ) ; System. out. p r i n t ( Los números son : ) ; 17 for ( int num : listanumeros ) 18 System. out. p r i n t (num + ) ; 19 System. out. p r i n t l n ( ) ; Código 5: Aplicación IngresoEnteros. Al ejecutar la aplicación IngresoEnteros y poner un dato válido para el primer número, se obtiene la siguiente salida, la cual sí muestra Ocurrió una excepción, pero al usuario no se le permite ingresar datos para cualquiera de los números restantes. El problema se puede corregir descomentando la llamada a nextline(), línea 14, del código anterior. De esta forma el mensaje de excepción es puesto, y se permite al usuario continuar ingresando datos. $ java IngresoEnteros Ingresa un entero >> a Ocurrió una excepción Ingresa un entero >> Ocurrió una excepción Ingresa un entero >> Ocurrió una excepción 9

10 Ingresa un entero >> Ocurrió una excepción Ingresa un entero >> Ocurrió una excepción Ingresa un entero >> Ocurrió una excepción Los números son: Actividad 1. Descomentar la línea 14 de la aplicación IngresoEnteros, compilar y ejecutar la apliación meter un dato no válido para observar que indica el error Declaración e inicialización de variables en bloques try...catch Se puede incluir cualquier sentencia legal dentro de un bloque try o catch, incluyendo la declaración de variables. Una variable declarada dentro de un bloque es local a ese bloque, por lo que esta variable sirve sólo para un propósito temporal. Si se quiere usar una variable tanto en un bloque try, como en un catch y después, entonces se debe declarar la variable antes de que el bloque try inicie. Si el valor inicial a esta variable se asignará dentro del bloque try...catch, se debe tener cuidado que la variable reciba un valor útil; de otra forma, cuando se use la variable después del bloque try...catch, el programa no compilará. En el programa PruebaVariableNoInicializada, código 6, x está declarada y su valor es asignado por la entrada del usuario en el bloque try...catch. Como el usuario podría no ingresar un entero, la conversión podría fallar, y una excepción podría ser lanzada. En este código el bloque catch sólo muestra un mensaje y no asigna un valor a x. Cuando el programa intenta mostrar x después del bloque catch, un mensaje de error es generado. Actividad 2. Compilar el código PruebaVariableNoInicializada para ver el mensaje de error. 1 import java. u t i l. Scanner ; 2 public class P r u e b a V a r i a b l e N o I n i c i a l i z a d a { 3 public static void main ( S t r i n g [ ] args ) { 4 int x ; 5 Scanner entrada = new Scanner ( System. in ) ; 6 try { 7 System. out. p r i n t ( I n g r e s a un entero ) ; 8 x = entrada. nextint ( ) ; 9 10 catch ( Exception e ) { 11 System. out. p r i n t l n ( Ocurrió e x c e p c i ón ) ; System. out. p r i n t l n ( x es + x ) ; Código 6: Aplicación PruebaVariableNoInicializada. Se tienen tres opciones para arreglar este error: Se puede asignar un valor a x antes de que el bloque try inicie. De esta forma, aún si una excepción es lanzada, x tendrá un valor usable para mostrar en la última sentencia. 10

11 Se puede asignar un valor usable a x dentro del bloque catch. De esta forma, si una excepción es lanzada, x tendrá otra vez un valor usable. Se puede mover la sentencia de salida al bloque try para que en el caso de que el usuario ingrese un entero muestre ese valor, y si la conversión falla entonces se deja el bloque try, para ser ejecutado el bloque catch mostrando el mensaje de error y sin usar x. Actividad 3. Modificar la aplicación DivisionPorCeroAtrapada que los enteros sean solicitados con cuadros de diálogo de entrada y el método Integer.ParseInt() para convertir las cadenas devueltas por los cuadros de diálogo de entrada en enteros. De igual forma modificar el bloque catch para mostrar el error con un cuadro de diálogo. 3. Lanzar y atrapar excepciones múltiples Se pueden poner tantas sentencias como se requiera dentro de un bloque try, y se pueden atrapar tantas excepciones como se quiera. Si se intenta más de una sentencia, sólo la primera sentencia generadora de error lanza una excepción. Tan pronto la excepción ocurre, la lógica se transfiere al bloque catch, lo cual deja el resto de las sentencias en el bloque try sin ejecutar. Cuando un programa contiene varios bloques catch, estos son examinados en secuencia hasta que un apareamiento es encontrado para el tipo de excepción que ha ocurrido. Entonces, el bloque catch apareado se ejecuta, y cada bloque catch restante es omitido. Considerar la aplicación DivisionPorCeroAtrapada3, código 7, donde el método main() lanza dos tipos de objetos Exception: una ArithmeticException y una InputMismatchException. El bloque try en la aplicación rodea todas las sentencias en la cual las excepciones podrían ocurrir. 11

12 1 import java. u t i l. ; 2 public class DivisionPorCeroAtrapada3 { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 try { 7 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 8 numerador = entrada. nextint ( ) ; 9 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 10 denominador = entrada. nextint ( ) ; 11 r e s u l t a d o = numerador / denominador ; 12 System. out. p r i n t l n ( numerador + / + denominador + 13 = + r e s u l t a d o ) ; catch ( Exception e ) { 16 System. out. p r i n t l n ( e. getmessage ( ) ) ; catch ( ArithmeticException e r r o r ) { 19 System. out. p r i n t l n ( e r r o r. getmessage ( ) ) ; catch ( InputMismatchException e r r o r ) { 22 System. out. p r i n t l n ( Tipo de dato i n c o r r e c t o ) ; Código 7: Aplicación DivisionPorCeroAtrapada3. Nota. La aplicación DivisionPorCeroAtrapada3 debe importar la clase java.util.inputmismatchexception para poder usar un objeto InputMismatchException. El paquete java.util es también ocupado por la clase Scanner, así que es más fácil importar el paquete completo. Nota. Si se usa el método getmessage() con el objeto InputMismatchException, se verá que el mensaje es null, porque null es el valor del mensaje por defecto para un objeto InputMismatchException. Para la aplicación DivisionPorCeroAtrapada3 el bloque try se ejecuta y varias salidas son posibles: Si el usuario ingresa dos enteros usables, resultado es calculado, la salida normal es mostrada, y ningún bloque catch se ejecuta. Si el usuario ingresa un valor no válido ya sea en la línea 7, o en la línea 9, un objeto InputMismatchException es creado y lanzado. Cuando el programa encuentra el primer bloque catch el bloque es pasado porque la excepción generada InputMismatchException no empata con ArithmeticException. Al encontrar el programa el segundo bloque catch, el tipo empata, y el mensaje Tipo de dato incorrecto es mostrado. Si el usuario ingresa cero para el denominador, la sentencia de división lanza una Arithmetic- Exception, y el bloque try es abandonado. Cuando el programa encuentra el primer bloque catch, el tipo de excepción empata, el valor del método getmessage() es mostrado, y luego el segundo bloque catch es pasado. 12

13 Cuando se ponen varios bloques catch siguiendo un bloque try, se debe tener cuidado de que algunos bloques catch no se hagan inalcanzables. Por ejemplo, si un primer bloque catch atrapan una ArithmeticException y enseguida otra atrapa una Exception, los errores ArithmeticException causan que el primer bloque catch se ejecute y otros tipos que deriven de Exception caigan al bloque catch Exception más general. Por otra parte, si se invierte la secuencia de los bloques catch para que atrape primero el bloque catch Exception, aún las ArithmeticException serán atrapadas por el primer catch, y de esta forma el bloque catch ArithmeticException será inalcanzable ya que la ArithmeticException será atrapada por el catch Exception, y por lo tanto la clase no compilará. Se deben de poner los bloques catch de forma que los más especializados estén primero y al final los más generales. Es decir, cada excepción deberá caer a través de tantos bloques catch como sea necesario hasta llegar con el que lo procesará. Nota. Otras sentencias que son inalcanzables son aquellas que siguen después de una sentencia return en un método. Crear bloques catch inalcanzables provoca un error del compilador que genera un mensaje indicando que la excepción has already been caught (ya ha sido atrapada). En ocasiones se quiere ejecutar el mismo código no importando cual tipo de excepción ocurre. En la aplicación DivisionPorCeroAtrapada3, código 7, cada uno de los dos bloques catch muestran un mensaje único, pero se podría querer que ambos bloques catch muestren el mismo mensaje. Como ArithmeticException e InputMismatchException son subclases de Exception, se puede reescribir el código 7, como se muestra en el código 8, usando un bloque catch genérico, líneas 15 17, que puede atrapar cualquier tipo de objeto Exception. 1 import java. u t i l. ; 2 public class DivisionPorCeroAtrapada4 { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int numerador, denominador, r e s u l t a d o ; 6 try { 7 System. out. p r i n t ( I n g r e s a r e l numerador >> ) ; 8 numerador = entrada. nextint ( ) ; 9 System. out. p r i n t ( I n g r e s a r e l denominador >> ) ; 10 denominador = entrada. nextint ( ) ; 11 r e s u l t a d o = numerador / denominador ; 12 System. out. p r i n t l n ( numerador + / + denominador + 13 = + r e s u l t a d o ) ; catch ( Exception e r r o r ) { 16 System. out. p r i n t l n ( Operación no e x i t o s a ) ; Código 8: Aplicación DivisionPorCeroAtrapada4. El bloque catch genérico de la clase DivisionPorCeroAtrapada4 acepta un tipo de argumento Exception genérico lanzado por cualquier sentencia potencialmente causante del error, así el bloque genérico actúa como un bloque atrapa todo. Cuando un error aritmético o de entrada ocurre, la excepción lanzada es promovida a un error Exception en el bloque catch. Actividad 4. Ejecutar la aplicación DivisionPorCeroAtrapada4 para ver que no importando el 13

14 tipo de error que ocurra durante la ejecución del programa, el mensaje general Operación no exitosa es mostrado Como una característica nueva en Java 7, un bloque catch ya puede ser escrito para atrapar múltiples tipos de excepciones específicas. Por ejemplo, el siguiente bloque catch atrapa dos tipos de excepciones. Cuando cualquiera es atrapada, su identificador local es e. catch (ArithmeticException, InputMismatchException e) {... Un método puede lanzar cualquier cantidad de tipos de excepciones, sin embargo varios programadores consideran que es un estilo pobre para un método lanzar y atrapar más de tres o cuatros tipos. Si lo hace, una de las siguientes condiciones podría ser cierta: Quizás el método está intentando realizar muchas tareas diversas y entonces debería ser dividido en métodos más pequeños. Quizás los tipos de excepción lanzados son muy específicos y deberían ser generalizados, como se hizo en la aplicación DivisionPorCeroAtrapada4, código 8. Actividad 5. Usar la actividad 2 para agregar un bloque catch que atrape un objeto NumberFormatException. Si este bloque se ejecuta, mostrar un mensaje de error, asignar a numerador y denominador el valor por defecto 999, y forzar resultado a uno. Ejecutar la aplicación para confirmar que el programa trabaja apropiadamente si se dan dos enteros usables, un cero no usable para el segundo entero, o datos no enteros como cadenas conteniendo caracteres alfabéticos o de puntuación. 4. Bloque finally Cuando se tienen acciones que se deben hacer al final de una secuencia try...catch, se puede usar un bloque finally. El código dentro de un bloque finally se ejecuta no importando si el bloque try precedente identifica una excepción. Generalmente, el bloque finally se usa para realizar tareas de limpieza que deben suceder no importando si alguna excepción ocurrió o no, y si cualquier excepción que ocurrió fue capturada o no. El siguiente formato muestra una secuencia try...catch que usa un bloque finally. try { // sentencias a intentar catch (Exception e) { // acciones que ocurren si Exception fue lanzada finally { // acciones que ocurren si el bloque catch fue ejecutado o no 14

15 En una secuencia try...catch que no incluya un bloque finally, ver el formato del cuadro 1, las sentencias opcionales que ocurren después del try, al final del método, podrían nunca ser ejecutadas por al menos dos razones. Cualquier bloque try podría lanzar un objeto Exception para el cual no se proporcione un bloque catch. En el caso de una excepción no manejada, la ejecución del programa termina inmediatamente, la excepción es mandada al sistema operativo para que la maneje, y el método actual es abandonado. El bloque try o catch podrían contener la sentencia System.exit();, la cual detiene la ejecución inmediatamente. Cuando se incluye un bloque finally, se asegura que las sentencias finally se ejecutarán antes que el método sea abandonado, aún si el método concluye prematuramente. Los programadores usan un bloque finally cuando el programa usa archivos de datos que deban cerrarse. El formato del cuadro representa parte de la lógica para un programa que maneja archivos. try { // Abrir el archivo // Leer el archivo // Colocar los datos del archivo en un arreglo // Calcular el promedio de los datos // Mostrar el promedio catch (IOException e) { // mostrar un mensaje de error // salir de la aplicación finally { // Si el archivo está abierto entonces cerrarlo. Cuadro 2: Pseudocódigo que intenta leer un archivo y manejar una excepción IOException El pseudocódigo del cuadro 2 representa una aplicación que abre un archivo; en Java, si un archivo no existe cuando se abre, una excepción entrada/salida, o IOException, es lanzada y el bloque catch puede manejar el error. Como el pseudocódigo usa un arreglo, una IndexOutOfBoundsException no atrapada podría ocurrir aún si se pudo abrir el archivo, esta excepción ocurre cuando un subíndice no está en rango de subíndices válidos. También podría dividirse por cero y una ArithmeticException no atrapada podría ocurrir. En cualquiera de estos eventos, se podrìa querer cerrar el archivo antes de proceder. Usando el bloque finally, se asegura que el archivo será cerrado porque el código en este bloque se ejecuta antes que el control regrese al sistema operativo. El código en el bloque finally se ejecuta no importando cual de las siguientes salidas del bloque try ocurra: El bloque try termina normalmente. El bloque catch se ejecuta. 15

16 Una excepción no capturada causa que el método sea abandonado prematuramente. Una excepción no capturada no permite que el bloque try concluya, ni causa que un bloque catch sea ejecutado. Si una aplicación pudiera lanzar varios tipos de excepciones, se puede intentar algún código, atrapar la posible excepción, intentar algún código más y atrapar la excepción, y así sucesivamente. La mejor alternativa es intentar todas las sentencias que podrían lanzar excepciones, y luego incluir todos los bloques catch necesarios y un bloque finally opcional. Esta es la alternativa mostrada en el cuadro 2, y resulta en un lógica que es más fácil de entender. Se puede evitar usar un bloque finally, pero se podría necesitar repetir código. Para el pseudocódigo del cuadro 2 para evitar usar el bloque finally se podría insertar la sentencia Si el archivo está abierto entonces cerrrarlo como la última sentencia en el bloque try y después de mostrar el mensaje de error en el bloque catch. Sin embargo, escribiendo código sólo una vez en el bloque finally es más simple y menos susceptible a error. Nota. Si un bloque try llama al método System.exit() y el bloque finally llama al mismo método, el método exit() en el bloque finally se ejecuta. La llamada del método exit() del bloque try es abandonado. 5. Ventajas del manejo de excepción Antes de la llegada de los lenguajes orientados al objeto, los errores potenciales del programa fueron manejados usando algo enredado, métodos propensos a error. Un programa procedural tradicional no orientado al objeto podría realizar tres métodos que dependen de otros usando código que proporcione revision similar al pseudocódigo del cuadro 3. llamar al metodoa() if metodoa() trabajó { llamar al metodob() if metodob() trabajó { llamar al metodoc() if metodoc() trabajó todo está bien, así que mostrar resultadofinal else poner códigoerror a C else poner códigoerror a B else poner códigoerror a A Cuadro 3: Pseudocódigo representando revisión tradicional de error 16

17 El pseudocódigo del cuadro 2 representa una aplicación en la cual la lógica deberá pasar tres pruebas antes de que resultadofinal pueda ser mostrado. El programa ejecuta el metodoa(); luego llama al metodob() sólo si metodoa() es exitoso. De igual forma, el metodoc() se ejecuta solo cuando ambos métodos metodoa() y metodob() son ambos exitosos. Cuando falla alguno de los métodos, el programa pone un código Á, B, o C apropiado en códigoerror, quizás códigoerror sea usado más tarde en la aplicación. La lógica es difícil de seguir, y el propósito de la aplicación y la salida usual intentada, mostrar resultadofinal, se pierde en laberinto de sentencias if. También, se pueden fácilmente cometer errores de codificación dentro del programa por el anidamiento complicado, sangrado, y apertura y cierre de llaves. Comparar la misma lógica del programa usando la técnica orientada al objeto, manejo de errores de Java mostrada en el cuadro 4. Usando la técnica try...catch se logran los mismos resultados que el método tradicional, pero las sentencias del programa que hacen el trabajo verdadero, la llamada a los métodos A, B, y C y mostrar resultadofinal, están puestos juntos, donde su lógica es más fácil de seguir. Los pasos try deberían usualmente trabajar sin generar errores; después de todo, los errores son excepciones. Es conveniente ver los pasos usuales en un solo lugar, y los eventos excepcionales están agrupados y puestos fuera de la acción primaria. try { llamar al metodoa() llamar al metodob() llamar al metodoc() catch (error del metodoa()){ poner códigoerror a A catch (error del metodob()){ poner códigoerror a B catch (error del metodoc()){ poner códigoerror a C Cuadro 4: Pseudocódigo representando el manejo de excepciones orientada al objeto Una ventaja del manejo de excepciones orientada al objeto, además de la claridad, es la flexibilidad que permite en el manejo de situaciones de error. Cuando un método escrito lanza una excepción, el mismo método puede atrapar la excepción, lo cual no es necesario y en la mayoría de los programas no se hace. Generalmente no se quiere que un método maneje su propia excepción. En muchos casos, se quiere que el método revise los errores, pero no se quiere hacer que un método maneje un error si este lo encuentra. Otra ventaja con el manejo de excepciones es que se tiene la habilidad para manejar apropiadamente las excepciones conforme se decide como hacerlo. Cuando se escribe un método, este puede llamar otro, atrapar una excepción lanzada, y se puede decidir que se quiere hacer. Los programas pueden reaccionar a excepciones específicas para sus propósitos actuales. Los métodos son flexibles en parte porque son reusables. Cada aplicación llamada podría necesitar manejar un error lanzado diferentemente, dependiendo de su propósito. Considerar una aplicación que usa un método que divide valores podría necesitar terminar si la división por cero ocurre. Un 17

18 programa diferente podría querer que el usuario reingrese el dato a ser usado, y un tercer programa podría querer forzar la división por uno. El método que contiene la sentencia de división podría lanzar el error, pero cada programa que llama puede asumir la responsabilidad para manejar el error detectado por el método en una forma apropiada. 6. Especificar excepciones que un método puede lanzar Si un método lanza una excepción que no atrapará pero que será atrapada por un método diferente, se debe usar la palabra reservada throws seguida por un tipo Exception en la cabecera del método. Esta práctica es conocida como especificación de excepción. En la clase ListaPrecios, código 9, usada por una empresa para tener una lista de precios de los artículos que venden, hay solamente cuatro precios y un sólo método que muestra el precio de un artículo individual. El método mostrarprecio() acepta un parámetro que será usado como el subíndice del arreglo, pero como el subíndice podría estar fuera de rango, el método contiene una cláusula throws en la línea 3, reconociendo que podría lanzar una excepción. 1 public class L i s t a P r e c i o s { 2 private static f i n a l double [ ] p r e c i o = { , , , ; 3 public static void mostrarprecio ( int a r t i c u l o ) throws IndexOutOfBoundsException { 4 System. out. p r i n t l n ( El p r e c i o es $ + p r e c i o [ a r t i c u l o ] ) ; 5 6 Código 9: La clase ListaPrecios. La aplicación AplicacionListaPrecios1, código 10, se ha escogido manejar la excepción en el bloque catch, líneas 11 13, para mostrar un precio de cero. 1 import java. u t i l. Scanner ; 2 public class A p l i c a c i o n L i s t a P r e c i o s 1 { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int a r t i c u l o ; 6 System. out. p r i n t ( I n g r e s a r e l número d e l a r t ículo >> ) ; 7 a r t i c u l o = entrada. nextint ( ) ; 8 try { 9 L i s t a P r e c i o s. mostrarprecio ( a r t i c u l o ) ; catch ( IndexOutOfBoundsException e r r o r ) { 12 System. out. p r i n t l n ( El p r e c i o es $0 ) ; Código 10: Clase AplicacionListaPrecios1. En la aplicación AplicacionListaPrecios2, código 11, el programador ha escogido manejar la excepciòn en el bloque catch, líneas 12 14, mostrando el precio del último artículo del arreglo. 18

19 1 import java. u t i l. ; 2 public class A p l i c a c i o n L i s t a P r e c i o s 2 { 3 public static void main ( S t r i n g [ ] args ) { 4 Scanner entrada = new Scanner ( System. in ) ; 5 int a r t i c u l o ; 6 f i n a l int ARTMAX = 3 ; 7 System. out. p r i n t ( I n g r e s a r e l número d e l a r t ículo >> ) ; 8 a r t i c u l o = entrada. nextint ( ) ; 9 try { 10 L i s t a P r e c i o s. mostrarprecio ( a r t i c u l o ) ; catch ( IndexOutOfBoundsException e r r o r ) { 13 L i s t a P r e c i o s. mostrarprecio (ARTMAX) ; Código 11: Clase AplicacionListaPrecios2. Otros programadores escribiendo otras aplicaciones que usen la clase ListaPrecios podrían escoger todavía acciones diferentes, pero pueden usar el método flexible mostrarprecio() porque este no limita la llamada de los métodos de recurso escogidos. Para la mayoría de los métodos Java que se escriben no se usa la cláusula throws. La mayoría del tiempo se le permite a Java manejar cualquier excepción abortando el programa, ya que de otra forma se requeriría dar instrucciones para manejar cada error posible. Muchas excepciones nunca tendrán que ser explícitamente lanzadas o atrapadas, ni se tendrán que incluir una cláusula throws en la cabecera de los métodos que automáticamente lanzan estas excepciones. Las únicas excepciones que deberán ser atrapadas o nombradas en una cláusula throws son del tipo conocido como excepciones comprobadas. Las excepciones de Java pueden ser categorizadas en dos tipos: Excepciones no comprobadas. Estas heredan de la clase Error o RuntimeException. Se pueden manejar estas excepciones en los programas, pero no se está obligado a hacerlo. Por ejemplo, dividir por cero es un tipo de RuntimeException, y no se está obligado a manejar esta excepción, se puede dejar que el programa termine. Excepciones comprobadas. Estas excepciones son del tipo donde los programadores podrían anticipar y de las cuales los programas deberían poderse recuperar. Todas las excepciones que explícitamente se lanzen y que desciendan de la clase Exception son excepciones comprobadas. Los programadores dicen que las excepciones comprobadas están sujetas al catch o especificamiento de requerimientos, lo cual significa que si se lanza una excepción comprobada desde un método, se debe hacer uno de los siguientes: Atrapar y manejar la excepción posible. Declarar la excepción en su cláusula throws. El método llamado puede entonces relanzar la excepción a otro método que podría atraparla o lanzarla otra vez. 19

20 Es decir, cuando una excepción es una comprobada, los programas clientes son forzados a negociar con la posibilidad que una excepción será lanzada. Si se escribe un método que explícitamente lanza una excepción comprobada que no es capturada dentro del método, Java requiere que se use la cláusula throws en la cabecera del método. Usando la cláusula throws no significa que el método lanzará una excepción, todo podría ir bien. En vez de esto significa que el método podría lanzar una excepción. Se incluye la cláusula throws en la cabecera del método para que las aplicaciones que usen los métodos estén notificados del potencial de una excepción. Nota. La firma del método es la combinación del nombre del método y la cantidad, tipo y orden de los argumentos. La cláusula throws no es parte de la firma porque no se puede crear una clase que contenga métodos múltiples que sólo difieran en sus cláusulas throws; el compilador considera que los métodos tienen firma idéntica. Se podría decir que la cláusula throws es parte de la interfaz del método. Nota. Un método que anule otro no puede lanzar una excepción a menos que esta lance el mismo tipo como su padre o una subclase del tipo lanzado de su padre. Estas reglas no aplican a métodos sobrecargados. Cualquier excepción podría o no ser lanzada de una versión de un método sobrecargado sin considerar que excepciones son lanzadas por otras versiones de un método sobrecargado. Para poder usar un método a su potencial completo, se debe conocer el nombre del método y tres piezas adicionales de información: El tipo regresado por el método. El tipo y número de argumentos que el método requiere. El tipo y cantidad de excepciones que el método lanza. Para usar un método, se debe saber que tipos de argumentos son requeridos. Se puede llamar un método sin saber su tipo devuelto, pero no se puede beneficiar de algún valor que el método devuelva, además no se entendería el propósito del método. De igual forma no se pueden hacer decisiones coherentes acerca de que hacer en caso de un error si no se sabe que tipos de excepciones un método podría lanzar. Cuando un método podría lanzar más de una tipo de excepción, se puede indicar una lista de las excepciones potenciales en la cabecera del método separándolas con comas. Como una alternativa, si todas las excepciones descienden del mismo padre, se puede especificar la clase padre más general. Si el método podría lanzar una ArithmeticException o una ArrayIndexOutOfBoundsException, se puede solo especificar que el método lanza una RuntimeException. Una ventaja de esta técnica es cuando el método es modificado para incluir RuntimeException más específico en el futuro, la cabecera del método no cambiará. Esto ahorra tiempo para los usuarios de los métodos, quienes no tendrán que modificar sus propios métodos para considerar nuevos tipos RuntimeException. Una alternativa extrema es especificar que el método lance un objeto Exception general, así todas las excepciones están incluidas en una cláusula. Con esto se simplifica la especificación de la excepción, pero se disfraza la información acerca de los tipos específicos de excepciones que podrían ocurrir, y esta información tiene valor para los usuarios de los métodos. 20

21 Nota. Se declaran solo excepciones comprobadas. Las excepciones tiempos de ejecución pueden ocurrir en cualquier parte del programa, y pueden ser numerosas. Los programas podrían ser menos limpios y más incómodos si se tiene que tener en cuenta las excepciones tiempos de ejecución en cada declaración del método. Por lo tanto, el compilador de Java no requiere que se atrape o se especifiquen excepciones tiempos de ejecución. 7. Traza de excepciones en la pila de llamadas Cuando un método llama a otro, el sistema operativo de la computadora deberá seguir la pista de donde provino la llamada del método, y el control del programa debe regresar al método llamador cuando el método llamado esté completo. Si el métodoa() llama al métodob(), el sistema operativo tiene que recordar regresar al métodoa() cuando el métodob() termine. De igual forma si el métodob() llama al métodoc(). La localidad de memoria conocida como la pila de llamadas es donde la computadora guarda la lista de la ubicación del método al cual el sistema deba regresar. Cuando un método lanza una excepción y el método no la atrapa, la excepción es lanzada al siguiente método de la pila de llamadas, o al método que llamó al método ofendido. Si el métodoa() llama al métodob(), y el métodob() llama al método métodoc(), y el métodoc() lanza una excepción, Java primero busca por un bloque catch en el métodoc(). Si ninguno existe, Java busca por la misma cosa en el métodob(). Si el métodob() no tiene un bloque catch, Java busca en métodoa(). Si el métodoa() no puede atrapar la excepción, esta es lanzada a la Máquina Virtual Java, la cual muestra un mensaje en la pantalla. La aplicación DemoTrazaPila, código 12, en el método main() llama al métodoa(), el cual muestra un mensaje y llama al métodob(). Dentro del métodob(), otro mensaje es mostrado y el métodoc() es llamado. En el métodoc(), otro mensaje es mostrado. Luego un arreglo de tres enteros es declarado, y el programa intenta mostrar el cuarto elemento del arreglo. El programa compila correctamente, pero un error es detectado cuando el métodoc() intenta acceder el elemento fuera del rango. 21

22 1 public c l a s s DemoTrazaPila { 2 public static void main ( S t r i n g [ ] args ) { 3 métodoa ( ) ; 4 5 public static void métodoa ( ) { 6 System. out. p r i n t l n ( En e l métodoa ( ) ) ; 7 métodob ( ) ; 8 9 public static void métodob ( ) { 10 System. out. p r i n t l n ( En e l métodob ( ) ) ; 11 métodoc ( ) ; public static void métodoc ( ) { 14 System. out. p r i n t l n ( En e l métodoc ( ) ) ; 15 int [ ] a r r e g l o = {0, 1, 2 ; 16 System. out. p r i n t l n ( a r r e g l o [ 3 ] ) ; Código 12: Clase DemoTrazaPila. Enseguida se muestra la salida cuando se ejecuta DemoTrazaPila que tiene tres mensajes, indicando el orden en el que fueron llamados los métodos métodoa(), métodob() y métodoc(). Sin embargo, cuando el métodoc() intenta acceder el elemento fuera de rango en el arreglo, una excepción ArrayIndexOutOfBoundsException es automáticamente lanzada. El mensaje de error genera muestra que la excepción ocurrió en la línea 16 del archivo en el métodoc(), el cual fue llamado en la línea 11 del archivo por el métodob(), el cual fue llamado en la línea 7 por el métodoa(), el cual fue llamado por el método main() en la línea 3 del archivo. Usando la lista de mensajes de error, se podría rastrear el lugar donde el error fue generado. Por supuesto, en una aplicación más granda que contenga miles de líneas de código, la lista del historial de seguimiento de la pila podría ser más útil. En el métodoa() En el métodob() En el métodoc() Exception in thread "main" java.lang.arrayindexoutofboundsexception: 3 at DemoTrazaPila.métodoC(DemoTrazaPila.java:16) at DemoTrazaPila.métodoB(DemoTrazaPila.java:11) at DemoTrazaPila.métodoA(DemoTrazaPila.java:7) at DemoTrazaPila.main(DemoTrazaPila.java:3) Cuando un programa usa varias clases, la desventaja es que el programador encuentra difícil encontrar la fuente original de una excepción. El método getmessage() de Throwable se usa para obtener información de un objeto Exception. Otro método útil de Exception es el método printstacktrace(). Cuando se atrapa un objeto Exception, se puede llamar printstacktrace() para mostrar una lista de métodos en la pila de llamadas y determinar el lugar de la sentencia que causó la excepción. La aplicación DemoTrazaPila2, código 13, en la cual el método printstacktrace() produce un seguimiento del camino tomado por el lanzamiento de una excepción. La llamada al métodob() 22