Excepciones Informática III

Ing. José L. Simón/Ing. Nora BletPág. 2 Objetivos Ver modelos de excepciones en lenguajes de programación Uso de excepciones para obtener tolerancia a fallos Ver en detalle el modelo de tratamiento de excepciones de Java

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 3 Excepciones y redundancia dinámica Son ocurrencias concretas de un error Cuando un componente detecta un error debe señalarlo al invocador lanzando (raise, signal, throw) una excepción La respuesta del invocador se denomina gestión (manejo, captura) de la excepción

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 4 Excepciones La gestión de excepciones se puede considerar como un mecanismo de recuperación hacia delante Sin embargo, también se pueden utilizar para proporcionar una recuperación de errores hacia atrás

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 5 Excepciones En la práctica, la mayor parte de un sistema, está dedicada a tratar con situaciones anormales, excepcionales o no deseadas; la parte más pequeña corresponde a la propia aplicación: más de 2/3 del código! está dedicada a la detección y manejo de errores (Cristian, 1982) Es muy probable que esta porción, contenga errores (bugs) ya que, además de su complejidad, rara vez se ejecuta y tampoco se ensaya adecuadamente El ejemplo más citado en la literatura es el accidente del cohete Ariane 5 debido a una excepción de software no manejada.

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 6 Excepciones: Caso del Ariane 5

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 7 Excepciones Las excepciones y su gestión pueden utilizarse para: Enfrentarse a condiciones anormales que surgen en el entorno (propósito original) Tolerar fallos en el diseño del programa Proporcionar unas capacidades de propósito general para la detección de errores y la recuperación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 8 Excepciones Aunque el trabajo de Goodenough (1975) puso los cimientos de la terminología relacionada con las excepciones, aún hoy día, no existe un acuerdo en la definición del concepto de excepción, como así tampoco en cuanto a su utilización En realidad, la palabra excepción sugiere “algo que ocurre muy raramente”. Sin embargo, esto se condice sólo parcialmente, con el uso que comúnmente se hace de ellas en la práctica diaria de la programación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 9 Excepciones Las excepciones constituyen una forma adicional de pasar información al invocante de un método Por tanto, resuelven el problema de los lenguajes de programación que permiten un único valor de retorno Pueden utilizarse para distintos propósitos. Goodenough (1975) señala 3: Errores ocurridos durante la invocación a un método Clasificar un resultado (Ej.: overflow, EOF) Monitoreo de eventos significativos que no siempre representan fallas (Ej. “se han procesado n registros”) Por tanto, no necesariamente indican “eventos excepcionales”. Ej.: en Java InterruptedException se utiliza para sincronizar threads

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 10 Excepciones y su uso Cuidado con su uso! Debería volverse a las raíces y recordar que las excepciones son excepcionales, usarlas para eventos raros (que no ocurren frecuentemente), no para el control del flujo normal. Lamentablemente no está de acuerdo con el uso actual de las excepciones en lenguajes tales como Java. En el siguiente ejemplo el 1º método es 750 veces más lento que el 2º (bajo Windows XP y Java 1.4) si se llama con una referencia que no sea del tipo Integer

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 11 Ejemplo public static boolean testForInteger1(Object x) { try { Integer i = (Integer) x; return true;} catch (Exception e) { return false;}} public static boolean testForInteger2(Object x) {return x instanceof Integer;}

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 12 Tareas típicas de un gestor de excepciones (Siedersleben, 2006) Registrar las circunstancias y continuar el trabajo, sólo en caso que los resultados anormales no sean graves desde el punto de vista del invocante de un método Registrar las circunstancias para los encargados de mantenimiento del sistema, limitar los daños (cerrar conexiones, resetear transacciones, etc.) y, finalmente decidir qué parte de la aplicación debe terminarse (normalmente una sesión, en el peor caso, el sistema completo).

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 13 Esperar un tiempo o ejecutar un número específico y razonable de reintentos de una operación Reconfiguración, es decir, reemplazar componentes por otros redundantes Tareas típicas de un gestor de excepciones (Siedersleben, 2006)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 14 Y luego?... Cada método tendrá sólo dos posibles resultados: Resultado normal: Esto incluye también aquellos que son errores de aplicación. El invocante del método no se entera si actuó el sistema de manejo de excepciones, a lo sumo puede percibir un tiempo de respuesta mayor al normal Parada “segura” y definitiva: El método finalmente falla; todos los intentos realizados por los mecanismos de manejo de excepciones no tuvieron éxito y, se tomaron todas las medidas apropiadas para limitar daños. No tiene sentido realizar ninguna acción de reparación posterior; la única opción que tiene el invocante es abortar la operación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 15 Modelo Actividad NormalManejador de Excepciones Vuelta al Servicio normal Excepción Interna Petición De Servicio Petición De Servicio Respuesta Normal Respuesta Normal Excepción de Interfaz Excepción de Fallo Excepción de Fallo Excepción de Interfaz

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 16 Manejo de Excepciones Un mecanismo de excepciones debe cumplir una serie de requisitos: R1 (simplicidad): Sencillo de comprender y utilizar R2 (discreción): Separación del código normal de código de tratamiento de excepciones R1 y R2 son cruciales en el diseño de sistemas fiables! R3 (eficiencia): Introduce sobrecarga en la ejecución sólo cuando se maneja una excepción R4 (uniformidad): Provee tratamiento uniforme de las excepciones del entorno y el software de aplicación R5 (recuperación): Permite la programación de acciones de recuperación (no solo predefinidas)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 17 Mecanismos de Manejo Retorno de un valor inusual (C) Bifurcación forzada (Assembler) goto no local Excepciones (C++, Java)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 18 Retorno de Valor Inusual (C) if( fopen(“archiv.dat”, “r”) != 0 ){ /* código de manejo de error */ } else { /* código normal */ }; R1  R2  R3  R4 R5

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 19 Bifurcación Forzada (Assembler) jsr pc, IMPRIME_SIMB jmp ERROR_ES jmp DISPOSITIVO_NO_PREPARADO # Procesamiento normal  R1  R2 R3  R4 R5

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 20 goto No Local (Salto incondicional global) on error goto err_sub// versión de alto nivel del anterior... Procedure Sub_1  R1...  R2 Endproc R3 Procedure Sub_2 R4 Endproc R5 Procedure err_sub // tratamiento de errores Endproc

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 21 Manejo de excepciones moderno Mecanismo estructurado para el tratamiento de las excepciones Provisto por el entorno de ejecución (runtime) Soportado directamente por el lenguaje de programación Provee tratamiento uniforme de las excepciones del entorno y del programa Mínima sobrecarga Soporte de múltiples manejadores de excepciones

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 22 Manejo de excepciones moderno Lenguajes que tienen incorporado el manejo de excepciones: C++ Java Visual Basic Delphi/Pearl/Eiffel/Ada… Todos los lenguajes.NET

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 23 Excepciones y su representación Síncronas: respuesta inmediata a una operación inapropiada de un fragmento de código Asíncronas (notificación asíncrona o señal): generadas tiempo después de la operación que da lugar a la aparición del error. Puede generarse desde el proceso que ejecutó la operación originalmente, o en otro (contexto de aplicaciones concurrentes)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 24 Clases de excepciones Detectada por el runtime y generada síncronamente: división por cero, error en índice de array Detectada por la aplicación y generada síncronamente: falla en assert Detectada por el runtime y generada asíncronamente: excepción generada por una avería en un dispositivo externo Detectada por la aplicación y generada asíncronamente: un proceso detecta una condición de error que causará que un proceso no cumpla los plazos o no termine correctamente

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 25 Excepciones síncronas Hay dos modelos para declararlas: Una constante  hace falta una declaración explícita (Ada) Un objeto de un tipo particular. No siempre hace falta declararlo explícitamente (Java)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 26 Excepciones en Java Las excepciones son objetos de una clase (Throwable) No hace falta declarar los objetos explícitamente El código de una aplicación o el entorno de ejecución pueden lanzar (throw) una excepción El manejador atrapa (catch) la excepción. Debe hacer referencia a la clase o a una superclase

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 27 Dominio de un Manejador de Excepciones Dentro de un programa puede haber varios manejadores para una misma excepción Cada manejador tiene asociado un dominio o ámbito, se trata de una región donde, si se produce la excepción, se ejecuta el manejador asociado La granularidad del dominio determinará qué tan precisamente puede localizarse la fuente de la excepción. No todos los lenguajes permiten alcanzar un nivel de granularidad adecuado

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 28 Dominio de un Manejador de Excepciones Bloque Protegido {//bloque vigilado(guarded) // sentencias que pueden generar una excepción } Manejador para Excepcion Tipo e1{ } Manejador para Excepcion Tipo en{ }

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 29 Ámbito de los manejadores en Java No todos los bloques pueden tener manejadores de excepciones El ámbito de un manejador se indica explícitamente mediante un bloque vigilado (guarded), se indica con un bloque try

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 30 Ámbito de los manejadores en Java Si se asocia un parámetro a la excepción que indique el punto donde se ha generado, el manejador puede usar esta información En Java la excepción es un objeto por tanto puede incluir tanta información como desee el programador

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 31 Ámbito de los manejadores en Java Es como una declaración de función, el parámetro es el tipo de excepción que atrapa Dentro del bloque el nombre del objeto es como una variable local Un manejador con parámetro de tipo T puede atrapar una excepción de tipo E si: T y E son del mismo tipo T es superclase de E (esto hace muy potente el mecanismo de manejo de excepciones de Java)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 32 Ámbito de los manejadores en Java try { } catch (FileNotFoundException e) { System.err.println("FileNotFoundException: "+ e.getMessage());//lanza excepción generada por //el usuario throw new SampleException(e);} catch (IOException e) {//otra distinta de //FileNotFoundException System.err.println("Caught IOException: " + e.getMessage());}

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 33 Propagación de excepciones Cuando no hay manejador en un bloque hay dos formas de proceder: Considerarlo un error de programación Debe notificarse en tiempo de compilación Puede ocurrir que una excepción generada en un procedimiento sólo pueda ser manejada apropiadamente en el contexto del invocante (Ej.:fallo en las precondiciones) El compilador no siempre puede comprobar si el contexto de llamada contiene los manejadores adecuados (análisis del control del flujo) Java permite que los procedimientos especifiquen qué excepciones pueden generar, es decir, cuáles no manejarán localmente, aunque, no requiere que exista un manejador disponible en el contexto del invocador Propagar la excepción (Java), es decir buscar manejadores en la cadena de invocaciones en tiempo de ejecución

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 34 Propagación de excepciones

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 35 Propagación de excepciones (García et al., 2001) Si un bloque o procedimiento no tiene un manejador adecuado para una excepción generada, esta se propaga hacia el invocador Si ningún procedimiento en la cadena de llamadas tiene un manejador adecuado, la excepción es manejada por el runtime, abortando el programa 2 soluciones de diseño: Propagación explícita (single-level): el manejo de excepciones se limita al invocante inmediato (puede generar nuevas excepciones o señalar la misma a su invocante) Propagación automática o implícita (multi-level): se propaga hasta que se encuentre un manejador

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 36 Catch all Muchos lenguajes proveen un manejador de tipo catch all. Posible solución en caso que el lenguaje precisa declarar el alcance de las excepciones.

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 37 Catch all en Java try { // statements which might raise the exception // IntegerConstraintError or ActuatorDead } catch(Exception E) { // handler will catch all exceptions of // type exception and any derived type; // but from within the handler only the // methods of Exception are accessible }

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 38 Tipos de enlace de manejadores/excepciones Enlace estático: Se efectúa en la compilación por lo que no permite la propagación, se ignora la cadena de invocaciones Enlace dinámico: Se realiza en ejecución y permite la propagación Es más flexible, representa mayor sobrecarga de ejecución Híbrido: Combinación de los 2 anteriores, permite propagación de excepciones (Java)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 39 Bloque finally en Java Java soporta una cláusula finally como parte de un bloque try-catch El código asociado a esta cláusula tiene garantizado su ejecución sin importar lo que ocurra con el que está en el bloque try Se utiliza para tareas de “limpieza”. Es una herramienta clave para prevenir pérdidas de recursos

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 40 Encadenamiento de excepciones en Java Una aplicación responde a una excepción lanzando otra Métodos y constructores que las soportan: Throwable getCause()//retorna la causa de la exc.actual Throwable initCause(Throwable)//retorna la exc.actual //el argumento es la exc. que causa la actual, ídem en constructores Throwable(String, Throwable) Throwable(Throwable) Ejemplo: try { } catch (IOException e) { throw new SampleException("Other IOException", e); }

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 41 Encadenamiento de excepciones en Java Un stack trace (método StackTraceElement[] getStackTrace() de Throwable ) provee información sobre la historia de la ejecución del thread actual y lista nombres de clases y métodos invocados desde el punto donde ocurrió una excepción Se suele utilizar como herramienta de debug

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 42 Encadenamiento de excepciones en Java catch (Exception cause) { StackTraceElement elements[] = cause.getStackTrace(); for (int i = 0, n = elements.length; i > " + elements[i].getMethodName() + "()"); } }

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 43 Encadenamiento de excepciones en Java Paquete java.util.logging permite hacer un registro (log) cuando ocurre una excepción en un bloque catch Ejemplo: try { Handler handler = new FileHandler("OutFile.log"); Logger.getLogger("").addHandler(handler); } catch (IOException e) { Logger logger = Logger.getLogger("package.name"); StackTraceElement elements[] = e.getStackTrace(); for (int i = 0, n = elements.length; i < n; i++) { logger.log(Level.WARNING, elements[i].getMethodName()); }

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 44 Modelos de Tratamiento de Excepciones Siempre debemos determinar que conducta tomará el programa ante la presencia de una excepción Recordar que el manejador es un procedimiento que se invoca implícitamente al generarse una excepción

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 45 Modelos de Tratamiento de Excepciones Si el manejador resuelve el problema y el invocador puede continuar su ejecución, puede aplicarse el modelo de reanudación (o de notificación) Si no se devuelve el control al invocador el modelo se denomina de terminación o escape En un modelo híbrido el manejador puede decidir qué hacer

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 46 Modelo de Reanudación P Hq Q Hr R 1.-P invoca Q 2.-Q invoca R 5.-Hq reanuda Hr 6.-Hr reanuda R 3.-R genera la excepción r 4.-Hr genera la excepción q

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 47 Modelo de Reanudación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 48 Modelo de reanudación Ventaja: Cuando la excepción se genera asíncronamente (tiene poco que ver con el proceso en ejecución actualmente), se puede reparar el daño y continuar Inconvenientes: Dificultad a la hora de reparar errores detectados por el entorno de ejecución Ejemplo: desborde aritmético en medio de una secuencia compleja de expresiones. Puede haber registros con evaluaciones parciales y el manejador puede sobreescribirlos Es difícil de realizar el modelo estricto: Puede ejecutarse nuevamente el bloque desde el principio (retry)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 49 Modelo de Terminación P Q R P invoca Q Q invoca R excepción Manejador Para R Terminación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 50 Modelo de terminación El control no retorna al punto donde apareció la excepción, sino que se finaliza el bloque o procedimiento que contiene el manejador y se pasa el control al bloque o procedimiento de llamada. Un procedimiento invocado puede terminar en condiciones: normal o de excepción Cuando el manejador está dentro de un bloque (Java) el control pasa a la primer sentencia que sigue al bloque que maneja la excepción

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 51 Excepciones y sistemas operativos El sistema operativo suele detectar síncronamente algunos errores (por ejemplo, violación de memoria) En los sistemas operativos convencionales se aborta el proceso en ejecución POSIX permite que la aplicación maneje las excepciones (mediante señales), asociando a cada excepción un manejador activado por el sistema cuando se detecta una condición de error Cuando el manejador termina, se reanuda el proceso (modelo de reanudación) Si el lenguaje soporta el modelo de terminación (como Java), el núcleo de ejecución (RTSS) se encarga de gestionarlo

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 52 Excepciones en Java Son objetos de una clase (Throwable) No hace falta declararlos explícitamente El código de la aplicación o el entorno de ejecución pueden lanzar (throw) una excepción El manejador apropiado la atrapa (catch). Debe hacer referencia a la clase o a una superclase Utiliza el modelo de terminación para el manejo de excepciones

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 53 Las tres clases de excepciones en Java Throwable ErrorException RuntimeErrors unchecked checked

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 54 Las tres clases de excepciones en Java Excepciones comprobadas (checked exceptions): condiciones excepcionales que pueden anticiparse y recuperarse de ellas. Ej.: incluir manejador para java.io.FileNotFoundException en código para manejar archivos Son todas aquellas que no son del tipo Error o RuntimeException o subclases de ellas Son manejadas en un bloque try o el método que las puede generar debe proveer una cláusula throws donde se las liste (Catch or specify requirement)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 55 Las tres clases de excepciones en Java Error: condiciones excepcionales externas a la aplicación y usualmente ésta no puede anticiparlas ni recuperarse de ellas. Ej.: java.io.IOError Error y subclases No están sujetos a los requerimientos de try o especificarlas en cláusulas throws. Igualmente pueden utilizarse (Ej.notificar al usuario o imprimir el stack trace y terminar)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 56 Las tres clases de excepciones en Java RunTimeException: Condiciones excepcionales internas a la aplicación y que usualmente la misma no puede anticipar o recuperarse de las mismas Usualmente indican errores de programación (bugs), con lo cual tiene más sentido corregirlos que atraparlos. Ej.: NullPointerException en lugar de un nombre de archivo pasado a FileReader Son de tipo RunTimeException o subclases No están sujetos a los requerimientos de try o especificarlas en cláusulas throws. Igualmente pueden utilizarse Las excepciones de este tipo y las de tipo Error son excepciones no comprobadas (unchecked exceptions)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 57 Declaración Cada función debe declarar una lista de las excepciones verificadas que puede lanzar usando throws A, B, C. A, B y C son subclases de Exception La función puede lanzar cualquiera de las listadas y cualquier excepción no verificada Si la función intenta lanzar una excepción que no esté en la lista, se produce un error de compilación

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 58 Resultados normales vs. Anormales (excepciones), Siedersleben (2006) Cada método cuando es invocado puede retornar básicamente dos tipos de resultados: Resultados normales Resultados anormales (excepciones) La decisión normal vs. anormal es binaria, no hay términos medios; además es local para el componente. Ej.: Una operación find() puede hallar 0 o muchos objetos que concuerden con la búsqueda (normal), aunque el invocante pueda considerarlo como anormal. Esta misma operación puede considerarse que retorna un resultado anormal si “se cae” la conexión a la base de datos aunque, el invocante del método puede intentar reconectarse a la base de datos y llamar a la operación nuevamente Si se mezclan es casi seguro que resultará en una violación de las reglas de abstracción de datos puesto que, el invocante de un método se ve confrontado con resultados de los cuales no es responsable y a los cuales tendría que manejar violando los principios de ocultamiento de la información

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 59 Resultados normales El resultado está al mismo nivel de abstracción de la interface del método La interface del método define todos los resultados normales del mismo. Los resultados son independientes de la implementación En la mayoría de los casos existen solo 1 o 2 resultados normales. Si existe un número mayor, debería cambiarse la interface. Por cada método todos los resultados normales son completamente enumerados como parte de las especificaciones Se consideran errores de la aplicación a aquéllos resultados normales, pueden que sean no deseados, aunque esperados. Ej.: En una rutina de manejo de archivo EOF puede considerarse un error pero es normal y esperado

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 60 Resultados anormales (excepciones) Anormal se usa como opuesto a normal No están al mismo nivel de abstracción que la interface del método Revelan detalles de implementación y se utilizan para eventos muy poco probables que ocurran. Si ocurren frecuentemente es debido a un diseño defectuoso y debería rediseñarse el método Pueden usarse también para indicar que un método fue invocado en forma inapropiada (Ej.: cuando se viola una precondición) Cualquier condición que no pueda manejarse en tiempo de ejecución son siempre anormales. Ej.: OutOfMemoryError

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 61 Resultados anormales (excepciones) Son dependientes de la implementación. Por tanto no es posible especificarlos en la interface del método (independiente de la implementación); pertenecen a la vista interna del componente, en la interface son irrelevantes. Nadie sería capaz de enumerarlos completamente todos los resultados anormales imaginables Interrumpen el flujo normal y demandan algún tratamiento especial. En algunos casos es posible continuar después de la ocurrencia pero, en otros, la única opción es detener el sistema

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 62 Ejemplo 1 Un componente CuentaBancaria tiene un método extraerDinero cuyos resultados normales son: ok, nohaysaldo y cuentabloqueada. Problemas relacionados con la conexión remota (indicado por una excepción RemoteException ) o acceso a la base de datos (indicado por ejemplo con una excepción SQLException ) son anormales; revelan detalles información de implementación ocultos. El problema reside más que en este hecho, en que el invocante no le conciernen estos problemas dependientes de la implementación del cual no es responsable

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 63 Ejemplo 2 Dentro de la misma aplicación el método conectarABasedatos en una capa de acceso. En este caso los resultados normales son ok y nok (si la base de datos no está accesible). Un problema de conexión remota (indicada por una excepción RemoteException ) sería considerado anormal, puesto que no tiene nada que ver con la interface de este método

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 64 ¿Cómo manejar errores de aplicación? Para los errores de aplicación que son resultados normales esperados (aunque tal vez no deseados) se utilizan valores de retorno especiales (Ej.: null ). Es mucho más elegante que manejar excepciones, principalmente en el caso de errores que ocurren a menudo (se evita la sobrecarga debido al uso de excepciones) Si no es posible, utilizar excepciones comprobadas (Java). En este caso, ser cauteloso: evite tanto tener métodos que lancen demasiadas excepciones comprobadas, como crear muchas nuevas excepciones (muchos bloques try-catch hace el código más largo y difícil de leer) Ejemplos: un método find() retornaría null o una lista vacía sino hay objetos que concuerden con la búsqueda. Un método extraerDinero que normalmente retorna el saldo después de una extracción lanzaría una excepción si la cuenta está sobregirada (por razones de performance, es esperable que ocurra raramente)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 65 ¿Cómo manejar resultados anormales? Las excepciones son resultados anormales de una invocación a un método, son inesperados En lo posible usar excepciones no comprobadas Nuevamente, se trata de evitar crear demasiadas excepciones nuevas

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 66 ¿Cuándo manejar los resultados anormales y errores de aplicación? Errores de aplicación deben manejarse localmente El invocante es capaz, está preparado y obligado a reaccionar en forma inmediata, frente a errores de aplicación, nunca deben propagarse Resultados anormales: El invocante normalmente no puede hacer mucho en respuesta al mismo; típicamente (salvo que el invocante pueda hacer algo en relación al problema o si se está en el nivel más alto de un componente, que es responsable de manejar todos los resultados anormales) se pasan hacia arriba en la pila de invocación y son manejados en un nivel más alto (no directamente en donde se realizó la invocación)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 67 Una jerarquía de tipos de excepciones (Guerra et. al., 2004)

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 68 Bibliografía Burns, A. Wellings, A. "Sistemas de Tiempo Real y Lenguajes de Programación", Addison-Wesley (2003) Capítulo 6 Transparencias de Juan Antonio de la Puente Cristian, F., Exception handling and software fault tolerance. IEEE Transactions on Computers, 31(6), pp. 531–540, 1982 Goodenough, J. B., Exception handling: Issues and a proposed notation. Communications of the ACM, 18(12), pp. 683–696, 1975

Informática IIIIng. José L. Simón/Ing. Nora BletPág. 69 Bibliografía Guerra, P. A. de C., Filho, F. C., Pagano, V. A. y Rubira, C. M. F., Structuring exception handling for dependable component-based software systems. EUROMICRO, pp. 575–582, 2004 Siedersleben, J., Errors and Exceptions— Rights and Obligations, Lecture Notes in Computer Science, vol. 4119, pp. 275–287. Springer Berlin / Heidelberg, 2006.