java - icon - ¿Por qué es SQLException una excepción marcada

usar codigo html en java

Question

¿Alguien puede pensar en una razón racional por la que la SQLException sea ​​una excepción comprobada ?

Sí, podría haber un error de sintaxis en la consulta
Sí, la conexión podría haber muerto.
Sí, podría haber un problema de permiso
Etc, etc. bla bla bla

Pero prácticamente el 100% del tiempo (una vez que se está ejecutando en producción), no hay ningún problema.

Si hay un problema, el código de llamada no puede hacer nada para recuperarse, por lo que, por ese motivo, debe estar desactivado .

Al comprobarse, se crean masas de bloques de try catch de ejecución en todo el código, como lo atestiguará cualquier persona que haya estado involucrada con un proyecto que utiliza JDBC. El desorden de códigos es significativo.

Debido a la naturaleza esotérica de SQL, la gran cantidad de razones por las que puede obtener una SQLException y su complejidad significa que, básicamente, no puede recuperarse, a menos que la excepción se deba a un problema de red temporal, pero incluso en una llamada sincrónica, de todos modos Debido a que no puede esperar indefinidamente a que se resuelva el problema de la red, tendrá que fallar la transacción.

Normalmente, llamar a SQL se ve así:

try {
// make some SQL call(s)
} catch {SQLException e) {
// log the exception
return; // and give up
}

Tal código no agrega ningún valor . No hay nada razonable que puedas hacer para recuperarte. También puede permitir que una excepción de tiempo de ejecución crezca, es decir, SQLException debería ser una excepción de tiempo de ejecución (sin marcar).

Answer 1

Hay un par de enfoques para el dilema verificado y no verificado. Verificar si el código de llamada puede recuperarse de la excepción o no es un enfoque, este, sin embargo, estoy de acuerdo, no explica por qué SQLExcption es una excepción comprobada .

Otro, proporcionado por Martin Fowler en su gran libro "Refactoring" sugiere verificar si es responsabilidad del llamado o del método llamado hacer una verificación que podría resultar en una excepción.

Si el método de la persona que llama debe realizar una verificación antes de llamar al método llamado (por ejemplo, asegurarse de que los argumentos no sean nulos), si esta verificación no se ha realizado, es claramente un error de programación y entonces el método llamado debe lanzar una excepción sin marcar.

Ahora bien, si el método llamado es responsable de realizar la verificación, ya que solo este método puede saber cómo realizar dicha verificación, se debe verificar la excepción generada por el método llamado .

En el caso de SQLException creo que solo esta clase puede saber:

• hay un error de sintaxis en la consulta ya que esto depende de la base de datos
• la conexión ha muerto
• hay un problema de permiso

Answer 2

Las excepciones de captura nos otorgan la capacidad de recuperarnos de condiciones excepcionales, es cierto, pero también nos permiten hacer otras cosas.

No puede recuperarse de una SQLException ya que no hay mucho que pueda hacer para solucionar el problema en tiempo de ejecución, pero hay algunas cosas útiles que puede hacer:

• Registre la excepción para la información de depuración
• Deshacer una transacción

Siempre puede registrar la excepción en un nivel superior (o inferior, según la perspectiva), pero pierde algo de valor semántico, tanto en el momento de la depuración como al revisar el código.

Si haces algo como:

try { ... }
catch(SQLException e)
{
SomeLogger.log(...);
rollback();
throw e;
}

y al volver a este código más tarde, instantáneamente se dará cuenta de que el código en el intento puede fallar sin tener que analizarlo mentalmente para determinar si puede fallar.

Otra cosa que podría hacer es asegurarse de que se hayan liberado los recursos de la base de datos, aunque no estoy seguro de que esto pueda suceder de la mano.

Answer 3

Una razón sería que un método debería lanzar una excepción que sea consistente con el nivel de abstracción de lo que hace el método.

Por lo tanto, un método que carga información de una base de datos no debe generar una SQLException , sino una excepción ResourceNotFoundException o ResourceUnavailableException .

Hacer que se verifique la SQLException es una forma de forzar al desarrollador a capturar la Excepción y envolverla en este nuevo nivel de abstracción.

Este argumento está tomado de Effective Java Second Edition por Joshua Bloch (Artículo 61: Lanzar excepciones apropiadas para la abstracción).

Answer 4

prácticamente el 100% de las veces no hay ningún problema : esto se limita a su propia observación que no dice nada sobre otros sistemas. Hay varios sistemas informáticos en todo el mundo con varios cuellos de botella. Su tasa de éxito es casi el 100%. Otros tienen que lidiar con un porcentaje mucho menor.

El error común es considerar la introducción / eliminación de una excepción marcada por la frecuencia con la que se produjo. Las excepciones comprobadas sirven como canales de comunicación. Como ustedes saben, cada método tiene su interfaz pública. De esta manera, el método nos dice qué argumentos acepta y cuál es el resultado del código en su cuerpo.

Cuando resulta imposible para un método que está actualmente en progreso mantener su promesa (por ejemplo, el valor devuelto) necesita una manera de decirle al otro método que algo salió mal y no puede hacer lo que se esperaba. Pero como hacerlo ? El envío del mensaje como el valor devuelto no funciona, casi no hay posibilidad de que el método de llamada distinga entre un valor adecuado y un mensaje de error. No quiere decir que algunos métodos no sean válidos como valor de retorno. Entonces, ¿qué hace cuando no puede mantener su promesa definida por la interfaz de su método? Bueno, tiras una excepción (enviar un mensaje).

Si espera ResultSet y no se establece conexión con su base de datos, ¿qué debe hacer? Volver vacío ResultSet? Diablos no, esto nos dice que la base de datos está vacía. Volver nulo? Bueno, esto solo delega el problema y hace que no se encuentre clara la causa.

Podría usar ese conjunto de resultados vacío y convertirlo en parte de otra consulta a otra base de datos, haciéndolo inconsistente.

Sin SQLException, incluso un error podría llevar a una inconsistencia de datos.