¿Qué subclase de Throwable deben ser capturados y que no debe?

Question

API doc dice que nunca se captura Throwable subclase Error que significa un comportamiento anormal. Hace que implica que la segregación entre error y de excepción es para decir que los programadores qué subclase debe ser capturado y cuáles no? O hay más?

Answer 1

En general, Error algo seriamente mal (a menudo dentro de la propia plataforma ) que no podía manejar concebible. Las únicas veces que he preocupaba por la captura de Error es con el fin de registrarlo , tras lo cual entonces me re-tiro.

Esto es de vital importancia, ya que es fácil dejar que los errores y excepciones (tiempo de ejecución) se propagan a la pila de llamadas de tal manera que nunca se registran (por ejemplo, utilizando executorService.submit(Runnable) sin escuchar el Future devuelto)

Errors suelen ser cosas como:

• fuera de la memoria
• error método abstracto (por ejemplo, correr contra diferente versión de bibliotecas a los construidos contra)
• Las afirmaciones (es decir, definido por el programador invariantes , o cosas que nunca debe suceder - lol)

Entonces diría que RuntimeExceptions son generalmente (aunque no siempre) indicativa de programación errores:

• no la comprobación de null, o pasando en nulo
• pasando en argumentos no válidos, o permitiendo estado no válido
• modificación de una colección como usted iterar sobre ella

Por lo general, recomendaría no-rápido en estos, así, pero esto es un área gris; tal vez usted no marca la entrada del usuario antes de pasarlo a la pena -apenas servidor de chocar su aplicación más!

Exceptions marcada (es decir, no en tiempo de ejecución) se debe utilizar para cosas que usted podría razonablemente esperar que suceda y razonablemente (o posiblemente) la manija en el código. Personalmente me gusta excepciones comprobadas pero estos son rendí engorroso debido a la verbosidad / repetición involucrado en el manejo de tipos de excepción distintas de la misma manera (es decir, en múltiples bloques de captura idénticos). Idiomas como el Scala tienen mucho mejor sintaxis de captura, pero luego se eliminó el concepto de excepciones, así!

Answer 2

Sí, creo que su análisis es correcto en este caso - no se supone que Errors de captura, ya que representan los errores de ejecución que no pueden ser recuperados de, como OutOfMemoryError.

La única razón para Throwable problema es si se está ejecutando el código de terceros externa que no es necesaria para el correcto funcionamiento de su programa - si usted no confía en que el código, captura todo y si te dan cosas que usted didn 't esperar (Throwable) y luego desactivar el código e informar de ello.

También podría ser una buena idea para distinguir entre Exception y RuntimeException.