He notado con Integer.parseInt() que no tiene que rodearlo con una captura de prueba o declarar que el método podría arrojar una excepción, a pesar de que "arroja" un NumberFormatException.¿Por qué no tienes que declarar explícitamente que puedes arrojar algunas excepciones integradas en Java?
¿Por qué no tengo que atrapar explícitamente el NumberFormatException o decir que mi método lo arroja?
Porque es una excepción de "tiempo de ejecución".
RuntimeExceptions se utilizan para identificar problemas de programación (que un buen programador podría evitar), mientras que
Las excepciones comprobadas se van a identificar los problemas de medio ambiente (que no se pudo evitar, no importa lo bueno que se realiza la programación, una servidor no funciona, por ejemplo)
se puede leer más sobre them here
en realidad, hay three kinds of exceptions, sólo uno de ellos debe ser h andled (la mayoría de las veces)
NumberFormatException extiende RuntimeException, no tiene que manejar explícitamente nada que herede de RuntimeException.
Otros RuntimeExceptions son cosas como NullPointerException y IndexOutOfBoundsException. Estas son cosas que el programador puede evitar y tener que probar/atrapar este tipo de excepciones crearía un código bastante desordenado.
Throwable
/ \
Error Exception
/ \
*checked* RuntimeException
\
*unchecked*
Ver Thinking in Java para una buena explicación de cuadros vs excepciones sin marcar.
Algunos consideran que la idea de las excepciones comprobadas es un experimento fallido. Por ejemplo, tanto Spring como Hibernate usan excepciones sin marcar, y a menudo envuelven excepciones marcadas en versiones no verificadas.
Solo un largo comentario sobre la respuesta del kit de herramientas.
La razón Las excepciones comprobadas son un problema es que pueden dar lugar a un código como éste:
try {
Something that throws an exception
} catch (Exception e) {}
Esto es peor de los casos. En primer lugar, no están registrando que están atrapando la excepción. Esto sucede mucho, y es casi OBLIGADO por excepciones muy estúpidas como la de Thread.sleep(), arroja InterruptedException que DEBE ser atrapada, pero el 99% del tiempo no te puede importar menos si tienes uno o no .
En el caso anterior, se complica por el hecho de que las personas tienden a simplemente detectar "Excepción" si hay más de una tirada. Eso significa que, incluso si se lanza una excepción crítica sin marcar, será atrapada e ignorada, lo que hace que sea virtualmente imposible encontrar el problema.
Más de una vez he estado en equipos que tuvieron que pasar aproximadamente un mes-hombre tratando de localizar errores ocultos de esta manera.
Es un buen concepto que se vuelve horrible cuando se agrega el hecho de que los humanos son los que deben implementarlo de manera responsable.
Esa es una mala descripción de la diferencia entre el tiempo de ejecución/excepciones marcadas. Eso es ** nada ** la diferencia entre ellos. Hay 'RuntimeException's que * debería * atrapar, y hay excepciones comprobadas que puede evitar haciendo comprobaciones adicionales antes de llamar al método. – Aaron
Ex1: 'NumberFormatException' es uno que normalmente debería capturar. Capturar 'NumberFormatException' es mejor que tratar de verificar el formato de un' String' antes de convertirlo a un número, ya que entonces * todavía * puedes terminar con 'NumberFormatException' que ahora no estás capturando. – Aaron
Ex2: 'IOException' es una que muchas API lanzan por todas partes. Esta es probablemente la excepción más atrapada para mí y la excepción más atrapada que veo en el código de otros también. Hay muchos lugares en los que se ve obligado a atrapar 'IOException' o sus subclases, donde nunca se lanzarán en algunos contextos de uso de la API que lo arroja. – Aaron