Unidad 7

MANEJO DE EXCEPCIONES
7.1 Introducción
Que es un error?
 “Un error es algo equivocado o desacertado. Puede ser una acción, un
concepto o una cosa que no se realizó de manera correcta”.
 En la matemática y en la física, el error es la diferencia que surge entre una
medición y la realidad. Pueden cometerse tanto errores de cálculo (producto
de un fallo en una operación matemática) como experimentales (ya que
resulta imposible ejercer un control preciso de alguna variable) o de
aproximación.
Errores informáticos
 En la informática, se diferencian básicamente los tipos de errores; el término
más comúnmente utilizado para referirse a ellos es bug, en inglés puede
significar insecto, y parece tener poco en común con un fallo de un programa.
 Existen diversas teorías acerca del origen del uso de esta palabra en tal
contexto. La más curiosa de ellas cuenta que Grace Hopper, creadora del
primer compilador para un lenguaje de programación, descubrió que una
especie de polilla que había quedado atrapada en un circuito provocaba
inconsistencias en el sistema.
7.1 Introducción
Fallas, errores, riesgos
No existen programas o sistemas que sean totalmente perfectos y
que estén exentos de algún tipo de fallos(también denominados
bugs), este tipo de errores pueden ser:
 Lógicos: Los resultados mostrados por el programa no son los
esperados.
 De ejecución: Aparecen mientras se ejecuta el programa,
aparecen cuando el programa intenta realizar operaciones
imposibles que se lleven a cabo.
 Sintácticos: Se producen al escribir mal el lenguaje que se está
usando.
 Estos errores pueden hacer desde que el sistema funcione de
manera inesperada hasta hacer que el programa tenga graves
fallos de seguridad, poniendo en peligro todo el sistema. Un error
en programación puede llevar a tener graves repercusiones y ser
bastante críticos.
 7.1 Introducción
ERRORES DE LA HISTORIA DEL SOFTWARE INFORMÁTICO
LA EXPLOSIÓN DEL ARIANE 5. MIL MILLONES DE DOLARES PERDIDOS
 ¿El problema? En gran parte, la reutilización de código, Ariane 5 reutilizó del Ariane 4. el causante del error fue que en una
parte del código se intentaba copiar una variable de 64 bits en una de 16 con el consiguiente error de overflow. Ejemplo
carísimo de la típica excusa “en mi computadora funciona”
EXCESO DE RADIACIÓN EN EL THERAC-25 MATÓ A CINCO PACIENTES
 Máquina de radiación Therac-25 que por un error en su software de control suministró un exceso de radiación a varios
pacientes provocando la muerte de al menos cinco de ellos.
MARS CLIMATE ORBITER. EL ERROR DE CONVERSIÓN QUE NOS DEJÓ SIN FOTOS DE MARTE
 Todo por un fallo tan “tonto” como un error de conversión. El sistema de control de la nave en la Tierra usaba el sistema
métrico anglosajón mientras que el sistema de navegación de la nave esperaba valores en el sistema métrico decimal. Esto
hizo que la trayectoria de la nave se acercara demasiado a Marte y se desintegró por fricción atmosférica del planeta (fuerza).
DESPLEGAR LA VERSIÓN INCORRECTA DEL SOFTWARE A PRODUCCIÓN TE CUESTA MÁS DE 400 MILLONES DE DOLARES EN 45 MINUTOS
 Error clásico, que costo al grupo Knight Capital 460 millones de dólares en menos de una hora. Y es que desplegar una nueva
versión del software a producción siempre es una operación de riesgo, especialmente en algoritmos de “trading”
especializados en la compra-venta de acciones casi instantáneas. Se les “olvidó” cambiar la configuración del algoritmo
para decirle que iba a ejecutarse en producción en lugar de en modo “TEST” (para probar su comportamiento en
condiciones extremas, se eliminan muchas de las restricciones que regulan su comportamiento). El algoritmos se dedicó a
comprar y vender alegremente sin evaluar las consecuencias.
EL PROBLEMA DEL AÑO 2000. EL “ERROR” QUE DIO DE COMER A MUCHOS INFORMÁTICOS
 Muchos programas antiguos almacenaban la fecha usando sólo dos dígitos para el año, para así ahorrar espacio. Con lo
que para ellos, el año 2000 sería 1900, lo que haría que, por ejemplo, jubilados dejaran de cobrar su pensión al rejuvenecer
100 años. Este tipo de error habitual (una excesiva optimización que no previó los efectos negativos a largo plazo).
7.1 Introducción
Tipos de Errores
 Error del usuario. Errores que se producen cuando el usuario realiza algo inesperado
y el programa no reacciona apropiadamente.
 Error del programador. Son errores que ha cometido el programador al generar el
código. La mayoría de errores son de este tipo.
 Errores de documentación. Ocurren cuando la documentación del programa no es
correcta y provoca fallos en el manejo.
 Error de interfaz. Ocurre si la interfaz de usuario de la aplicación es difícil de
entender para el usuario impidiendo su manejo normal. También se llaman así los
errores de protocolo entre dispositivos.
 Error de entrada/salida o de comunicaciones. Ocurre cuando falla la comunicación
entre el programa y un dispositivo (se desea imprimir y no hay papel, falla en la red)
 Error fatal. Ocurre cuando el hardware produce una situación inesperado que el
software no puede controlar (el ordenador se cuelga, errores en la grabación de
datos)
 Error de ejecución. Ocurren cuando la ejecución del programa es más lenta de lo
previsto.
Una de las tareas del programador es predecir, encontrar y subsanar (si es posible) o al
menos controlar los errores. Una mala gestión de errores causa experiencias poco
gratas al usuario de la aplicación.
7.2 Causa de las excepciones
Las excepciones son algunos errores en el programa, pero no todos los errores son
excepciones, y algunas veces se pueden evitar estos errores.
Hay muchas razones por las se produce una excepción, por lo general contiene las
siguientes categorías:
 Los datos de entrada del usuario ilegales.
 Al abrir un archivo que no existe.
 conexión de comunicación de la red, desbordamiento de memoria interrumpido o JVM.
Entre algunas causas de situaciones de error se tienen:
 Implementación incorrecta
 No se ajusta a las especificaciones
 Petición de objeto inapropiada
 Índice inválido
 Referencia nula
 Estado de objeto inapropiado o inconsistente, por ejemplo debido a una extensión de la
clase.
 7.3 Manejo de las excepciones
 Una excepción es un error que ocurre en tiempo de ejecución. Utilizando el
subsistema de manejo de excepciones de Java, se puede, de una manera
estructurada y controlada, manejar los errores de tiempo de ejecución.
 Aunque la mayoría de los lenguajes de programación modernos ofrecen algún tipo
de manejo de excepciones, el soporte de Java es fácil de usar y flexible.
 Para entender el manejo de excepciones de Java es saber cómo funciona,
teniendo e cuenta los siguientes tipos de excepciones:
 excepción comprobada: el más representativo marcada excepción es una
excepción debido a errores del usuario o un problema, es el programador
imprevisible. Por ejemplo, si desea abrir un archivo que no existe, se produce una
excepción, la excepción no puede ser simplemente ignorado en tiempo de
compilación.
 Excepción es probable que sea un programador para evitar un funcionamiento
anormal: tiempo de ejecución es una excepción. En contraste con la excepción
comprobada, a excepción de tiempo de ejecución puede ser ignorada en tiempo
de compilación.
 Error: error no es anormal, sino de la cuestión del control del programador. Error en el
código son generalmente ignorados. Por ejemplo, cuando se produce un error de un
desbordamiento de pila, no pueden comprobar en tiempo de compilación.
7.4 Jerarquía de las excepciones
 Todas las clases de excepción heredan de la subclase
java.lang.Exception.
 La clase de excepción es una subclase de la clase Throwable.
Además de la clase de excepción, Throwable hay una subclase
de error.
 Los programas Java no suelen detectar el error. El error ocurre
generalmente cuando se produce una falta grave, que son
visibles fuera de la ejecución del programa Java.
 El entorno de ejecución de error se utiliza para indicar si un error se
produce.
 Por ejemplo, la JVM de desbordamiento de memoria. En general,
el programa no se recupera a partir del error. La clase de
excepción tiene dos subcategorías principales: clase IOException
y de clase RuntimeException.
7.4 Jerarquía de las excepciones
7.4 Jerarquía
de las
excepciones
 7.5 Tipos de excepciones
Tenemos 3 grandes tipos en la clasificación de las excepciones, las que ocurren
cuando hay un error de sistema, las que ocurren cuando hay un error en el tiempo
de ejecución y las excepciones de las clases.
Errores de sistema
 Este tipo de excepciones son arrojadas cuando ocurren por la Java Virtual
Machine (JVM), y están comprendidas dentro de la clase Error, estas se utilizan
para describir errores internos del sistema, aunque realmente este tipo de errores
ocurre con muy poca frecuencia y no podemos hacer mucho más que informar
al usuario y terminar el programa.
Excepciones en tiempo de ejecución
 Están representadas por la clase RuntimeException como habíamos indicado y
se utiliza para describir errores de programación, como por ejemplo una
declaración no adecuada de una variable, el uso de un tipo de dato prohibido.
Excepciones
 Este tipo está representado por la clase Exception y describe los problemas que
pueden ocurrir en nuestro programa y que podemos manejar, de forma que el
usuario no vea terminada la aplicación de forma abrupta.
7.6 Excepciones
predefinidas
Las excepciones predefinidas
por la implementación actual
del lenguaje Java y su jerarquía
interna de clases son:
7.6 Excepciones predefinidas
Excepciones predefinidas en resumen:
 ArithmeticException
 NullPointerException
 IncompatibleClassChangeException
 ClassCastException
 NegativeArraySizeException
 OutOfMemoryException
 NoClassDefFoundException
 ArrayIndexOutOfBoundsException
 UnsatisfiedLinkException
 InternalException
7.7 Excepciones propias
 El programador puede lanzar sus propias excepciones, extendiendo la clase
System.exception.
 Por ejemplo, considérese un programa cliente/servidor. El código cliente intenta conectar al
servidor, y durante 5 segundos espera a que conteste el servidor. Si el servidor no responde, el
servidor lanzaría la excepción de time-out:
class ServerTimeOutException extends Exception {}
 Cualquier método que lance una excepción también debe capturarla, o declararla como
parte del interfaz del método. Al lanzar una excepción hay que capturarla en el mismo
método. Las excepciones no simplifican el trabajo del control de errores. Tienen la ventaja de
que se puede tener muy localizado el control de errores y no hay que controlar millones de
valores de retorno, pero no van más allá.
 Se puede crear excepciones propias y no utilizar las múltiples que ya proporciona Java.
Como guía, se pueden plantear las siguientes cuestiones, y si la respuesta es afirmativa, lo
más adecuado será implementar una clase Exception nueva y, en caso contrario, utilizar
una del sistema.
 ¿Se necesita un tipo de excepción no representado en las que proporciona el entorno de
desarrollo Java?
 ¿Ayudaría a los usuarios si pudiesen diferenciar las excepciones propias de las que lanzan
las clases de otros desarrolladores?
 ¿Si se lanzan las excepciones propias, los usuarios tendrán acceso a esas excepciones?
 ¿El package propio debe ser independiente y auto-contenido?
7.8 Excepciones no manejadas por el método que las generó (throws)
 Si un método es capaz de provocar una excepción que no
maneja él mismo, debería especificar este comportamiento, para
que todos los métodos que lo llamen puedan colocar
protecciones frente a esa excepción.
 La palabra clave throws se utiliza para identificar la lista posible de
excepciones que un método puede lanzar. Para la mayoría de la
subclase de la clase Exception, el compilador Java obliga a
declarar qué tipos podrá lanzar un método.
 Si el tipo de excepción es Error o RuntimeException, o cualquiera
de sus subclases, no se aplica esta regla, dado que no se espera
que se produzcan como resultado del funcionamiento normal del
programa.
 Si un método lanza explícitamente una instancia de Exception o
de sus subclases, a excepción de la excepción de runtime, se
debe declarar su tipo con la sentencia throws. La declaración del
método sigue ahora la sintaxis siguiente:
 7.9 Funcionamiento try-catch-finally
BLOQUE TRY
 Try en inglés es el verbo intentar, así que todo el código que vaya dentro de esta sentencia será el código sobre el que se
intentará capturar el error si se produce y una vez capturado hacer algo con él. Lo ideal es que no ocurra un error, pero en
caso de que ocurra un bloque try nos permite estar preparados para capturarlo y tratarlo. Así un ejemplo sería:
try {
System.out.println(“bloque de código donde pudiera saltar un error es este”);
}

BLOQUE CATCH
 En este bloque definimos el conjunto de instrucciones necesarias o de tratamiento del problema capturado con el bloque
try anterior. Es decir, cuando se produce un error o excepción en el código que se encuentra dentro de un bloque try,
pasamos directamente a ejecutar el conjunto de sentencias que tengamos en el bloque catch.
 catch (Exception e) {
System.out.println(“bloque de código donde se trata el problema”);
}
 Después de catch hemos puesto unos paréntesis donde pone “Exception e”. Esto significa que cuando se produce un error
Java genera un objeto de tipo Exception con la información sobre el error y este objeto se envía al bloque catch.
BLOQUE FINALLY
 Y para finalizar tenemos el bloque finally que es un bloque donde podremos definir un conjunto de instrucciones necesarias
tanto si se produce error o excepción como si no y que por tanto se ejecuta siempre.
finally {
System.out.println(“bloque de código ejecutado siempre”);
}
 7.10 Tratamiento de errores o Excepciones
 Java es un lenguaje compilado, por lo tanto durante el desarrollo pueden darse dos
tipos de errores: los de tiempo de compilación y los de tiempo de ejecución. En
general es preferible que los lenguajes de compilación estén diseñados de tal
manera que la compilación pueda detectar el máximo número posible de errores.
 Es preferible que los errores de tiempo de ejecución se deban a situaciones
inesperadas y no a descuidos del programador. Los errores de tiempo de ejecución
siempre habrán, y su gestión a través de excepciones es fundamental en cualquier
lenguaje de programación actual.
Errores en tiempo de ejecución: Excepciones
 Los errores en tiempo de ejecución son aquellos que ocurren de manera inesperada:
disco duro lleno, error de red, división por cero, cast inválido. Todos estos errores
pueden ser manejados a través de excepciones. También hay errores debidos a
tareas multihilo que ocurren en tiempo de ejecución y no todos se pueden controlar.
Por ejemplo un bloqueo entre hilos sería muy difícil de controlar y habría que añadir
algún mecanismo que detecte esta situación y mate los hilos que corresponda.
 Las excepciones son eventos que ocurren durante la ejecución de un programa y
hacen que éste salga de su flujo normal de instrucciones. Este mecanismo permite
tratar los errores de una forma elegante, ya que separa el código para el tratamiento
de errores del código normal del programa. Se dice que una excepción es lanzada
cuando se produce un error, y esta excepción puede ser capturada para tratar
dicho error.
Captura de excepciones
try {
// Código regular del programa
// Puede producir excepciones
} catch(TipoDeExcepcion1 e1) {
// Código que trata las excepciones de tipo
// TipoDeExcepcion1 o subclases de ella.
// Los datos sobre la excepción los encontraremos
// en el objeto e1.
} catch(TipoDeExcepcion2 e2) {
// Código que trata las excepciones de tipo
// TipoDeExcepcion2 o subclases de ella.
// Los datos sobre la excepción los encontraremos
// en el objeto e2.
...
} catch(TipoDeExcepcionN eN) {
// Código que trata las excepciones de tipo
// TipoDeExcepcionN o subclases de ella.
// Los datos sobre la excepción los encontraremos
// en el objeto eN.
} finally {
// Código de finalización (opcional)
}
Lanzamiento de excepciones
 En el bloque catch pueden ser útiles algunos métodos de la excepción (que podemos
ver en la API de la clase padre Exception):
 con getMessage obtenemos una cadena descriptiva del error (si la hay). Con
printStackTrace se muestra por la salida estándar la traza de errores que se han
producido (en ocasiones la traza es muy larga y no puede seguirse toda en pantalla con
algunos sistemas operativos).
 Nunca deberemos dejar vacío el cuerpo del catch, porque si se produce el error, nadie
se va a dar cuenta de que se ha producido. En especial, cuando estemos con
excepciones no-checked.

String getMessage()
void printStackTrace()

try {
... // Aqui va el codigo que puede lanzar una excepcion
} catch (Exception e) {
System.out.println ("El error es: " + e.getMessage());
e.printStackTrace();
}
Creación de nuevas excepciones
 Para crear un nuevo tipo de excepciones simplemente deberemos crear una clase que
herede de Exception o cualquier otro subgrupo de excepciones existente. En esta clase
podremos añadir métodos y propiedades para almacenar información relativa a nuestro
tipo de error.
 Además podremos crear subclases de nuestro nuevo tipo de excepción, creando de
esta forma grupos de excepciones. Para utilizar estas excepciones (capturarlas y/o
lanzarlas) hacemos lo mismo que lo explicado antes para las excepciones que se tienen
definidas en Java.

public class MiExcepcion extends Exception

{
public MiExcepcion (String mensaje)
{
super(mensaje);
}
}
FIN