practice - try catch api java

¿Por qué no tenemos que agregar try-catch a una RuntimeException? (7)

Quiero preguntar por qué no tenemos que agregar el bloque try-catch a una RuntimeException mientras que deberíamos hacerlo con otras excepciones.

Me refiero a como

public class Main { public static void main(String[] args) { throw new RuntimeException(); } }

Editar: cuando digo: throw new RuntimeException(); es tan claro que habrá una excepción, entonces ¿por qué el compilador no lo prohíbe?

Básicamente, una excepción no detectada es solo una abreviatura para mostrar un mensaje y finalizar la aplicación.

¿Por qué necesitarías hacer eso? En algunos casos, puede detectar que algo salió mal, algunos archivos no se cargaron, falta una API, algunos datos están dañados por alguna razón o una de un millón de otras cosas está mal. Si no lanza una excepción, la aplicación simplemente puede fallar en otro punto o, en el peor de los casos, seguir ejecutándose mientras el error se intensifica, lo que dificulta mucho más la depuración.

Es importante entender que uno lanza una excepción porque hay un error, la excepción no es el error, es solo el mensajero.

De acuerdo con la especificación de idioma, las excepciones no verificadas no se verifican en tiempo de compilación, lo que significa que el compilador no requiere métodos para capturarlas o especificarlas (con throws ). Las clases que pertenecen a esta categoría se detallan en la sección 11.2 Verificación en tiempo de compilación de las excepciones del JLS:

Las clases de excepciones no verificadas son la clase RuntimeException y sus subclases, y la clase Error y sus subclases . Todas las demás clases de excepción son clases de excepción marcadas . La API de Java define una serie de clases de excepción, tanto marcadas como desactivadas. Los programadores pueden declarar clases de excepción adicionales, tanto marcadas como no marcadas. Consulte §11.5 para obtener una descripción de la jerarquía de clases de excepción y algunas de las clases de excepción definidas por la API de Java y la máquina virtual de Java.

Entonces, debido a una excepción RuntimeException en una excepción no verificada, el compilador no te obliga a manejarlo. Si desea forzar a la persona que llama a un fragmento de código para que maneje una excepción, use una excepción marcada (las subclases de Exception no sean RuntimeException son todas clases de excepción marcadas).

Eso es porque es una excepción sin control . No necesita ser declarado o capturado explícitamente. También vea el tutorial de Sun sobre el tema .

Actualización: en general, solo debe lanzar una RuntimeException (preferiblemente una de sus subclasses listadas en el javadoc) para indicar que la persona que llama lo está haciendo mal. Es decir, pasar un argumento null (luego lanzar NullPointerException ), o un argumento ilegal (luego lanzar IllegalArgumentException ), o el método se llama en el momento / estado incorrecto (luego lanzar IllegalStateException ), etc. Se supone que la persona que llama debe arreglar su código para evitar eso. Por ejemplo, comprobar de antemano si el argumento no es nulo, o si el argumento tiene el formato / sintaxis correctos, o asegurarse de que se llame al método en el momento adecuado.

Si hay una situación específica que debería lanzar una excepción de tiempo de ejecución y no puede usar una de sus subclases, entonces se supone que debe extenderla y documentarla correctamente en el javadoc de la nueva excepción y en el método de llamada, por ejemplo, ConfigurationException extends RuntimeException en el caso de que el código de llamada no haya configurado la aplicación / API correctamente antes del uso. Esto debería indicar al usuario final (el otro desarrollador) lo suficiente como para actuar en consecuencia.

En pocas palabras: subclasses debe identificar los problemas recuperables mediante programación que son causados por fallas en el flujo de código o la configuración (lea: fallas del desarrollador). Las Exceptions verificadas deben identificar los problemas recuperables de manera programática que son causados por condiciones inesperadas fuera del control del código (por ejemplo, la base de datos, el error de E / S del archivo, la entrada incorrecta del usuario final, etc.). Errors deben identificar problemas no recuperables de manera programática (por ejemplo, sin memoria, excepción dentro de un inicializador, etc.).

La mayoría de las respuestas en este foro han estado hablando sobre la jerarquía de Excepciones y el compilador de Java que no las detecta, pero intentaría responder esto más desde la perspectiva del diseño y por qué quizás las cosas se diseñaron de esta manera.

Básicamente, cuando se llama a una función (o se escribe algún código), se puede descartar una excepción en función de tres situaciones diferentes:

Basado en una condición inevitable como la falta de disponibilidad de la red o la falta de algún archivo esperado en el sistema de archivos.
Basado en una condición evitable pero conocida como Integer.parseInt(String) puede lanzar NumberFormatException si la persona que llama pasa una cadena no convertible como "Hello" , pero la persona que llama puede asegurar las validaciones adecuadas antes de pasar cualquier cadena a la función y eliminarla completamente. Con la posibilidad de generar la excepción. Un caso de uso común podría ser validar la age campo de formulario en una página web antes de pasarla a capas más profundas que realizan la conversión.
Una condición desconocida o inesperada Cada vez que una línea de código puede lanzar una excepción en su código porque hubo algún error que cometió y no observó la condición de error hasta que se disparó en la producción, generalmente ocurre con NullPointer Reference , IndexOutOfBounds , etc. que si se observa, posiblemente caiga en la categoría 2.

Las excepciones de la categoría 1 generalmente se diseñan como Checked Exceptions porque deben imponer la verificación de condiciones de error inevitables y hacer cumplir sus reservas. Por ejemplo, IOException es una excepción comprobada, porque en caso de que abra un archivo, puede haber muchas cosas que pueden salir mal (como el archivo puede ser eliminado, permisos, etc.) y la validación previa de todas ellas puede ser muy complicada.

Las excepciones del segundo tipo generalmente se modelan como Unchecked Exceptions porque puede tener su validación previa en su lugar y puede ser irritante verse obligado a usar el método de intentar y capturar situaciones que ya ha solucionado.

Las excepciones del 3er tipo no tienen que preocuparse por lo general, ya que no puede colocar el manejo de errores en cada una de las declaraciones de código de aplicación que pueden surgir inesperadamente. Pero a veces puede colocar un controlador global, en algún lugar bastante arriba en la pila de llamadas desde donde se ejecuta casi todo el código de la aplicación y manejarlo de manera genérica para que su aplicación no se bloquee debido a un error inesperado.

Por ejemplo, si está ejecutando una aplicación web, puede configurar su Servlet Container para enviar un 500 Internal Server Error genérico de 500 Internal Server Error por cualquier error no manejado en su aplicación. O, si está ejecutando una aplicación Java independiente, puede mantener el contenido de su main method en un bloque try catch para evitar que la aplicación se bloquee.

Porque no está prohibido lanzar excepciones de tiempo de ejecución y no tiene que declarar excepciones de tiempo de ejecución. Su programa es un programa Java válido, por lo que el compilador no tiene motivos para quejarse.

Vamos a discutir de esta manera. ¿Qué pasa si NullPointerException fue diseñado para ser una excepción de tiempo de compilación? Si se hubiera hecho así, el compilador tuvo que verificar estrictamente si una variable es nula o no. No hay manera de que esto se pueda hacer.

public void dummyMethod(Object obj){ }

Aquí no hay forma de que el compilador compruebe si el objeto puede ser nulo o no. Sin embargo, tiene que haber algún error / excepción que se debe lanzar cuando se tiene un escenario de puntero nulo.

RuntimeException , Error y sus subclases no se verifican específicamente en tiempo de compilación, no forman parte del contrato formal del método.

Consulte el Capítulo 11 en JLS, Excepciones, en particular 11.2, Verificación de excepciones en tiempo de compilación.

JLS, cap. 11, Excepciones.