14

¿Cuáles son las excepciones de tiempo de ejecución y cuáles son las excepciones controladas/no comprobadas y la diferencia entre error/excepción? ¿Por qué estos muchos tipos? En cambio, Java simplemente puede seguir un diseño simple (simplemente intente/atrape todos los tipos) para manejar una condición anormal en un programa.Diferencias entre Tiempo de ejecución/Controlado/Sin marcar/Error/Excepción

+0

¿Has leído la lección [Sun Java Tutorials on exceptions] (http://java.sun.com/docs/books/tutorial/essential/exceptions/)? Ese es probablemente un buen lugar para comenzar. –

Respuesta

27

Throwable está en la parte superior de todas las excepciones. Debajo de Throwable tienes Error y Excepción. Por debajo de Exception tienes RuntimeException.

Java tiene dos tipos de excepciones: marcadas y sin marcar. El compilador impone excepciones controladas (debe declararlas en la cláusula throws y capturarlas eventualmente). Las excepciones no verificadas no se aplican para atrapar o declarar en la cláusula throws.

(parte controvertida de la respuesta)

Throwable existe para que haya un padre para todos los tipos de excepción. Nunca debes declarar que arrojas a Throwable y nunca lo atrapes (a menos que realmente realmente sepas lo que estás haciendo).

Existe un error que indica problemas con el entorno de ejecución, cosas que su programa probablemente no puede recuperar, como un archivo de clase mal formateado o la VM que se queda sin memoria. No debería detectar un error a menos que realmente sepa lo que está haciendo.

Existe una excepción como raíz de todos los errores no programados (vea RuntimeException para la "excepción" a esto), como que no se puede crear un archivo porque el disco está lleno. No debe arrojar, arrojar o atrapar Excepción. Si tiene que atrapar Exception, asegúrese de saber lo que está haciendo.

RuntimeException existe para indicar todos los errores del programador, como ir más allá del final de una matriz o llamar a un método en un objeto nulo. Estas son las cosas que debe corregir para que no arrojen excepciones: indican que usted, el programador, arruinó el código. De nuevo, no deberías atrapar estos a menos que sepas lo que estás haciendo.

3

@ La respuesta de TofuBeer explica claramente lo que significan las clases de excepción.

Why these many types? Instead Java may simply follow a simple design(just try/catch all types) to handle an abnormal condition in a program?

¿Por qué? Porque son necesarios! Sin esas 4 clases, manejar las excepciones por categoría amplia no sería práctico.

  • ¿Cómo captarías "todos los errores fatales de JVM" sin la clase Error?
  • ¿Cómo captarías "todas las excepciones que no son errores fatales JVM" sin la clase Exception?
  • ¿Cómo captarías "todas las excepciones sin marcar" sin la clase RuntimeException?
0

Las Excepciones de tiempo de ejecución le ofrecen la flexibilidad de evitar la captura, declarando las excepciones.

+2

Sí, como si no fuera una excepción y simplemente dejar que matara el hilo es una solución aceptable. – Bombe

+0

En algunos casos, lo es. – Sid

+0

Por lo general, se considera una Bad Idea® para generar su propia 'RuntimeException'. Hazlo con cuidado, y no solo como un atajo. –

16

Como soy un nuevo desarrollador de Java, también he enfrentado algunas dificultades para distinguir y manejar diferentes tipos de excepciones. Es por eso que he hecho una breve nota sobre este tema, y ​​cada vez que me confundo lo reviso. Aquí está con la imagen de la jerarquía de clases Throwable:
Throwable Class Hierarchy

[imagen por cortesía de JavaTpoint].

Hay tres clases clave para recordar aquí: Throwable, Exception y Error. Entre estas clases, Exception se pueden dividir en dos tipos: "Excepción comprobada" y "Excepción no verificada".

excepción comprobada:

  • Estas son las clases que se extienden Throwable excepto RuntimeException y Error.
  • También se conocen como excepciones de tiempo de compilación, ya que se comprueban en tiempo de compilación, lo que significa que el compilador nos obliga a manejarlas con try/catch o indicar en la función que las throws y nos obliga a tratarlas en la persona que llama .
  • Son problemas recuperables mediante programación que son causados ​​por condiciones inesperadas fuera del control del código (por ejemplo, base de datos inactiva, error de E/S de archivo, entrada incorrecta, etc.).
  • Ejemplo:IOException, SQLException, etc.

Excepción Desactivada:

  • Las clases que se extienden RuntimeException se conocen como excepciones sin marcar.
  • Las excepciones no comprobadas no se verifican en tiempo de compilación, sino en tiempo de ejecución, de ahí el nombre.
  • También son problemas recuperables mediante programación pero, a diferencia de , excepción comprobada, son causados ​​por fallas en el flujo o la configuración del código.
  • Ejemplo:ArithmeticException, NullPointerException, ArrayIndexOutOfBoundsException, etc.
  • Puesto que son errores de programación, que se pueden evitar por muy bien/codificación sabiamente. Por ejemplo, "dividir por cero" produce un ArithmeticException, que se puede evitar con una simple comprobación en el divisor. Del mismo modo, podemos evitar NullPointerException simplemente marcando las referencias: if (object != null) o incluso usando better techniques.

Error:

  • Error se refiere a una situación irrecuperable que no está siendo manejada por un try/catch.
  • Ejemplo:OutOfMemoryError, VirtualMachineError, AssertionError, etc.

por qué esto muchos tipos?

Además de respuesta Stephen C 's quiero decir: manejo de excepciones es una operación relativamente cara en Java. No deberíamos poner todas las situaciones excepcionales en un bloque try/catch.El uso excesivo de try/catch s puede obstaculizar el rendimiento del programa.

En conclusión, Exception s deben manejarse mediante programación siempre que sea posible. Por otro lado, no podemos manejar Error s, por lo que estas pueden ser algunas razones lógicas por las que hay muchos tipos de excepciones.

+0

+1 para la bonita foto. Sidenote: no es estrictamente correcto que un 'Error' no sea capturable. Nadie te impide escribir 'try {sometching(); } catch (Error e) {} ', pero en realidad es una mala idea hacer esto (ver [@ TofuBeer's answer] (https://stackoverflow.com/a/3162916/2448440) para más detalles). – Qw3ry

0
  • error (lanza por máquina virtual, no debe ser capturado o manipulado)
    1. VM Error
    2. aserción error
    3. Vinculación error ... etc.
  • tiempo de ejecución/Desmarcar Excepción (error de programación, no debe ser capturado ni manejado)
    1. NullPointerException
    2. ArrayIndexOutOfBoundException
    3. IllegalArgumentException ... etc.
  • excepción de comprobación (Todo lo demás, se espera que las aplicaciones a ser capturado o manipulado)
    1. IOException
    2. FileNotFoundException
    3. SQLException ... así sucesivamente