Universidad de Guayaquil

Facultad de ingeniera Industrial

L.S.I

Grupo #4 nocturno

Integrantes:
Coello Blgica
Chvez Edwin
Gurumendi David
Soto Carlos

Profesora: Miss Isabel Guales

2015-2016

Gestin de excepciones en Java. Captura con

bloques try catch finally.
INTRODUCCIN: GESTIN EXCEPCIONES EN JAVA
A continuacin vamos a ver como el lenguaje Java implementa su propio sistema de gestin de
excepciones, o como hemos mencionado anteriormente, tambin llamado sistema de tratamiento de
errores. Tambin veremos los primeros ejemplos sencillos sobre la gestin de excepciones.

EL SISTEMA DE GESTIN DE EXCEPCIONES

El control de flujo de un programa Java sabemos hasta ahora que se lleva a cabo con sentencias del tipo
if, while, for, return, break, etc Estas sentencias forman un conjunto de palabras reservardas que
determinan cierta funcionalidad. Pues bien, ninguna de ellas tiene en cuenta que se puedan producir
errores en tiempo de ejecucin de un programa y por tanto Java necesita de un conjunto de palabras
nuevas para tener en cuenta que cualquier cdigo puede fallar o ser mal interpretado en tiempo de
ejecucin.
Vamos a ver tres de las palabras reservadas para tratamiento de excepciones:
- Try.
- Catch.
- Finally.
Aunque posteriormente veremos otras palabras ms avanzadas y otras formas de tratamiento de errores,
stas son las primeras y ms bsicas con las que vamos a trabajar.
De forma introductoria diremos que hay dos formas de tratar errores en Java: capturarlos o lanzarlos. El
uso de try catch finally corresponde a la captura de errores. Vamos a poner un smil sencillo: un error
es algo inesperado, como encontrarte un ladrn dentro de tu casa. Cuando nos encontramos con un error

podemos capturarlo (equivaldra a capturar el ladrn) o lanzarlo (equivaldra a tratar de hacer huir al
ladrn, de hacer que salga fuera del lugar donde se encuentra).
BLOQUE TRY
Try en ingls es el verbo intentar, as que todo el cdigo que vaya dentro de esta sentencia ser el cdigo
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 sera:

try {
System.out.println(bloque de cdigo 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 excepcin en el cdigo que se
encuentra dentro de un bloque try, pasamos directamente a ejecutar el conjunto de sentencias que
tengamos en el bloque catch. Esto no es exactamente as pero ya explicaremos ms adelante todo el
funcionamiento. De momento para una mejor comprensin vamos a considerar que esto es as.

catch (Exception e) {
System.out.println(bloque de cdigo donde se trata el problema);
}

Fjate que despus de catch hemos puesto unos parntesis donde pone Exception e. Esto significa que
cuando se produce un error Java genera un objeto de tipo Exception con la informacin sobre el error y
este objeto se enva 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 excepcin como si no y que por tanto se ejecuta
siempre.

finally {
System.out.println(bloque de cdigo ejecutado siempre);
}

EJEMPLO SIN ERROR

A continuacin vamos a ver cmo se comporta un programa con tratamiento de errores pero donde no se
produce ningn error. Escribe este cdigo en tu editor.

/* Ejemplo Gestin de Excepciones Java aprenderaprogramar.com */

public class Programa {
public static void main (String [] args)

try{
System.out.println("Intentamos ejecutar el bloque de instrucciones:");
System.out.println("Instruccin 1.");

System.out.println("Instruccin 2.");

System.out.println("Instruccin 3, etc.");
}
catch (Exception e) { System.out.println("Instrucciones a ejecutar cuando se produce un
error"); }
finally{ System.out.println("Instrucciones a ejecutar finalmente tanto si se producen errores
como si no."); }
}
}

La salida obtenida tras ejecutar el programa anterior es:

Como podemos observar, se han ejecutado todas las instrucciones del bloque try y finalmente se ejecut
la instruccin del bloque finally. No se ejecuta el bloque catch porque no hubo error.
EJEMPLO CON ERROR
A continuacin vamos a ver cmo se comporta un programa con tratamiento de errores cuando se
produce un error y cmo afecta al control de flujo del programa. Escribe este cdigo en tu editor.

/* Ejemplo Gestin de Excepciones Java aprenderaprogramar.com */

public class Programa {
public static void main (String [] args)

try {
System.out.println("Intentamos ejecutar el bloque de instrucciones:");
System.out.println("Instruccin 1.");
int n = Integer.parseInt("M"); //error forzado en tiempo de ejecucin.
System.out.println("Instruccin 2.");
System.out.println("Instruccin 3, etc.");
}
catch (Exception e) {
System.out.println("Instrucciones a ejecutar cuando se produce un error");
}
finally {
System.out.println("Instrucciones a ejecutar finalmente tanto si se producen errores como si
no.");
}
}
}

Se produce un error porque el mtodo parseInt de la clase Integer espera que dentro de las comillas
llegue un nmero y no una letra. Por ejemplo int n = Integer.parseInt("65"); sirve para transformar el String
65 en un int de valor 65. Al no encontrar un valor vlido se produce un error de tipo
java.lang.NumberFormatException.
La salida obtenida en este caso donde se produce error es:

Prueba a escribir dentro del bloque catch lo siguiente: System.out.println("Se ha producido un error "+ e );
Trata de interpretar lo que se visualiza en pantalla. Si tienes dudas consulta en los foros de
aprenderaprogramar.com.
Como podemos observar, ejecutamos las instrucciones del bloque try que no dan errores, pero cuando en
una instruccin se produce un error o excepcin inesperada se deja de ejecutar el cdigo del bloque try, y
pasamos a ejecutar el cdigo del bloque catch. Hay un salto o cambio en el flujo del programa.
Finalmente se ejecutan, en todo caso, las instrucciones del bloque finally como hemos comentado
anteriormente. El bloque finally no es obligatorio, es decir, puede existir un bloque try catch y no existir
bloque finally.

Manejo de transacciones java

Estrategia de transaccin
La clave para la captacin de transacciones de Spring es la nocin de una estrategia de operacin. Una
estrategia

de

operacin

se

define

por

la

interfaz

de

org.springframework.transaction.PlatformTransactionManager, que se muestra a continuacin:

public interface PlatformTransactionManager {

TransactionStatus getTransaction(TransactionDefinition definition)
throws TransactionException;
void commit(TransactionStatus status) throws TransactionException;
void rollback(TransactionStatus status) throws TransactionException;
}
Tengamos en cuenta que, de acuerdo con la filosofa del marco de Spring, PlatformTransactionManager es una
interfaz y, por lo tanto, puede ser fcilmente implementada cuando sea necesario. Tampoco est vinculada a
una estrategia de bsqueda como JNDI. Las implementaciones PlatformTransactionManager se definen como
cualquier otro objeto (o bean) en el contenedor de Spring Framework COI. Este beneficio slo se hace con un
objetivo de abstraccin. Incluso cuando se trabaja con JTA, los cdigos de transaccin pueden ser probados con
mayor facilidad que si se utiliza directamente JTA.
Una vez ms, en consonancia con la filosofa de Spring, el TransactionException que puede ser lanzado por
cualquiera de los mtodos de la interfaz de PlatformTransactionManager siendo unchecked (es decir, se
extiende la clase java.lang.RuntimeException).
Los fallos en la infraestructura de transaccin son casi siempre definitivos. En pocos casos el cdigo de
aplicacin puede recuperarse de un error de transaccin, el desarrollador de aplicaciones an puede elegir
capturar y manejar TransactionException. El punto importante es que los desarrolladores no estn obligados a
hacerlo.
El mtodo getTransaction (..) devuelve un objeto TransactionStatus, en funcin de un parmetro
TransactionDefinition. El TransactionStatus devuelto podra representar una operacin nueva o ya existente (si
hay una transaccin coincidente en la pila de llamadas actual con la implicacin de que un TransactionStatus se
asocia con un hilo de ejecucin).
La interfaz de TransactionDefinition especifica:

Aislamiento: el grado de aislamiento de esta transaccin sobre otras transacciones. Por ejemplo, esta
transaccin puede verse comprometida por la escritura de otras transacciones?

Propagacin: en general, todo cdigo que se ejecuta dentro de un mbito de transaccin se ejecutar
en esa transaccin. Sin embargo, hay varias opciones que especifican el comportamiento si se ejecuta un
mtodo de transaccin cuando el contexto de la transaccin ya existe: por ejemplo, slo tiene que seguir
corriendo en la operacin existente (el caso ms comn), o la suspensin de la operacin existente y la creacin
de una nueva transaccin. Spring ofrece todas las opciones de transaccin de propagacin familiares de EJB
CMT.

Tiempo de espera: cunto tiempo tiene la transaccin para ejecutarse antes del tiempo de espera (y
automticamente se deshace de la infraestructura de transaccin subyacente).

Estado de slo lectura: una transaccin de lectura nica no puede modificar ningn dato. Las
transacciones de slo lectura pueden ser una optimizacin de utilidad en algunos casos (como cuando se utiliza
Hibernate).
La interfaz de TransactionStatus proporciona una forma sencilla para el cdigo de transaccin para controlar la
ejecucin de transacciones y estado de la transaccin de consulta. Los conceptos deben estar familiarizados, ya
que son comunes a todas las API de transacciones:

public interface TransactionStatus {

boolean isNewTransaction();
void setRollbackOnly();
boolean isRollbackOnly();
}
Independientemente de si se opta por la gestin de transacciones declarativa o programtica en Spring, la
definicin de PlatformTransactionManager correcta es absolutamente esencial. En Spring , esta importante
definicin generalmente se realiza mediante la inyeccin de dependencias. Las implementaciones
PlatformTransactionManager normalmente requieren el conocimiento del entorno en el que trabajan: JDBC, JTA,
Hibernate, etc

Construccin de Aplicaciones por Capas

La programacin por capas es un estilo de programacin en el que el objetivo primordial es la separacin de la
lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la
capa de presentacin al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo
en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al nivel requerido sin tener que
revisar cdigo entremezclado.
Se agrupan por cada capa una serie de recomendaciones basadas en el modelo de tres capas propuesto en el
subsistema de Arquitectura, en el reaArquitectura Tecnolgica, de MADEJA. Se han realizado estudios y
recomendaciones sobre de las tecnologas ms recomendables para la arquitectura propuesta y se presentan
una serie de pautas tanto a nivel funcional como para la construccin e integracin de cada capa.
La ventaja de la variedad de tecnologas disponibles para el desarrollo de las diferentes capas de las
aplicaciones Java, presenta el inconveniente de la utilizacin conjunta de varias de ellas. Debido a esto se
deben establecer unos criterios que hagan posible una integracin ptima entre las tecnologas empleadas.
Estos criterios se han recogido en forma de pautas que se describen en esta

Prueba unitaria
En programacin, una prueba unitaria es una forma de comprobar el correcto
funcionamiento de un mdulo de cdigo. Esto sirve para asegurar que cada uno de los

mdulos funcione correctamente por separado. Luego, con las Pruebas de Integracin, se
podr asegurar el correcto funcionamiento del sistema o subsistema en cuestin.
La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo, de
forma que cada caso sea independiente del resto.

Caractersticas
Para que una prueba unitaria tenga la calidad suficiente se deben cumplir los siguientes
requisitos:
Automatizable
No

debera

requerirse

una

intervencin

manual.

Esto

es

especialmente

til

para integracin continua.

Completas
Deben cubrir la mayor cantidad de cdigo.
Repetibles o Reutilizables
No se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til
para integracin continua.
Independientes
La ejecucin de una prueba no debe afectar a la ejecucin de otra.
Profesionales
Las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad,
documentacin, etc.
Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda
seguirlos o de lo contrario las pruebas pierden parte de su funcin.

Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las
partes individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo
debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas bsicas:
Fomentan el cambio
Las pruebas unitarias facilitan que el programador cambie el cdigo para mejorar su
estructura (lo que se ha dado en llamar refactorizacin), puesto que permiten hacer
pruebas sobre los cambios y as asegurarse de que los nuevos cambios no han
introducido errores.
Simplifica la integracin
Puesto que permiten llegar a la fase de integracin con un grado alto de seguridad de que
el cdigo est funcionando correctamente. De esta manera se facilitan laspruebas de
integracin.
Documenta el cdigo

Las propias pruebas son documentacin del cdigo puesto que ah se puede ver cmo
utilizarlo.
Separacin de la interfaz y la implementacin
Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son
las interfaces de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro,
a veces usando objetos mock (mock object) para simular el comportamiento de objetos
complejos.
Los errores estn ms acotados y son ms fciles de localizar
Dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones
Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores
del cdigo. Algunos enfoques se basan en la generacin aleatoria de objetos para
amplificar el alcance de las pruebas de unidad. 1 Esta tcnica se conoce como testing
aleatorio (RT, por random testing). Por definicin, slo prueban las unidades por s solas.
Por lo tanto, no descubrirn errores de integracin, problemas de rendimiento y otros
problemas que afectan a todo el sistema en su conjunto. Adems, puede no ser trivial
anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de
programa bajo estudio. Las pruebas unitarias slo son efectivas si se usan en conjunto con
otras pruebas de software.