Ayuda con Java, excepciones

robb

Buenas, este martes tengo examen de Programación y estoy haciendome un lio con la excepciones.

He estado buscando en google y no me acabo de aclarar del todo.

Entiendo que una excepción se puede propagar, lanzar y capturar.

Lo de capturarla lo entiendo perfectamente (try catch blabla).

Sé que para propagarla es añadir en la cabezera throws yelerror, y para lanzarla throw new elerror, pero no entiendo la diferencia entre estos dos últimos.

No entiendo de qué sirve lanzar y propagar, y en que se diferencia, y por qué usar esas y no capturarlo directamente.

A ver si podéis ayudarme, gracias de antemano.

Spacelord

Si entiendo bien lo que estás preguntando (estoy algo espeso hoy, si ves que no es lo que te digo avísame):

Try-catch sirve para tratar la excepción en el mismo bloque en el que salta. Aparece la excepción en el try, el código salta al catch, la captura y la ejecución sigue tranquilamente. Esto es capturar una excepción.

En cambio, la cláusula throws en la definición de un método sirve para indicar que, si salta una excepción DENTRO de ese método, se pasa a la excepción especificada en el throw. Esto es propagar la excepción, porque pasa (se propaga) del bloque en el que ha saltado a la clase que la trata. En el caso de JDBC, por ejemplo, añadir un trhows SQLException al método que hace la conexión significa que el método donde salte la excepción invocará a SQLException, que es quien captura la excepción y la trata.

Lanzar una excepción es especificar en el código que la quieres lanzar. Normalmente, con un throw new Exception(). Habrá momentos en los que te sea más útil lanzarla directamente, como por ejemplo dentro de un catch.

2 2 respuestas
B

#2 +1

Al final tienes que decidir donde capturar y donde lanzar, lo importante de las excepciones es que no se pierdan, ya que al final son errores "controlados". Yo personalmente no suelo tratarlas directamente donde surgen (a no ser que sea en capas altas de la arquitectura). Exceptions en capas de bbdd las suelo propagar, ya que considero que los errores de inserción, updateo y borrado de datos son errores que deben afectar al funcionamiento de la aplicación mediante un control. Ejemplo:

  1. Capa bbdd: ERROR-XXX: Duplicated keys...blablabla (Suele dar al insertar algo que , por clave primaria, esta ya en la bbdd, por tanto no se puede volver a insertar) -> PROPAGO
  2. Capa Pepito: ----> Propago
  3. Capa que influye en el comportamiento visual de la aplicación -> TRATO Y HAGO SABER AL USUARIO QUE NO PUEDE INSERTAR ESOS DATOS

Claro, esto es uno de los muchos ejemplos que puedes tener mediante excepciones en java (y en cualquier lenguaje)

Suerte.

1 respuesta
robb

Muchas gracias #2 y #3 ya me ha quedado claro :D

1
cabron

De forma resumida, cuando ocurra un error dentro de un método tienes que decidir que responsabilidad tiene ese método sobre ese error:

try catch = lo tengo todo controlado, sé lo que que hay que hacer cuando ocurra este error

throw = no tengo ni puta de idea de que hacer cuando ocurra este error, que se coma el marrón otro

Y en el último caso, a veces el método puede decir: "ok, no tengo ni puta idea de que que hacer con esto, pero voy a ayudar un poco al que le toque arreglarlo", entonces en lugar de de simplemente propagar la misma excepción, creas una nueva donde puedes añadir información de lo que el método estaba haciendo cuando ocurrió el error.

2
MTX_Anubis

También añadir que entre diferentes capas de la aplicación no deberían propagarse excepciones específicas y que las excepciones deberían tratarse en cuanto puedan ser solucionadas.

Un ejemplo rápido entre DAOs y Services, un Service nunca debería conocer las excepciones de persistencia de datos, por ejemplo, SQLException. Estas deberían ser capturadas por el propio DAO y lanzar nuevas excepciones específicas.

Eso es basicamente para evitar más acoplamiento entre capas aunque en la práctica la peña se lo pasa por el forro y además que toda tu aplicación no dependa de frameworks o librerías externas, sólo la capa correspondiente.

1 respuesta
B

Como bien dice #6, cuando en #3 hablaba de propagar la exception de base de datos, no hablaba de la SQLException pura, es mejor llevarte una tuya con la identificación del error en concreto.

Por otro lado, #1, jamás pienses de la siguiente forma "tiro un catch que no haga nada para que compile"... trata la exception siempre, al menos para dejar en un supuesto log que algo extraño ha ocurrido.

1

Usuarios habituales