java - catch - exception runtimeexception

Diferencias entre Runtime/Checked/Unchecked/Error/Exception

Question

¿Cuáles son las excepciones en tiempo de ejecución y cuáles son las excepciones marcadas / no marcadas y la diferencia entre error / excepción? ¿Por qué estos tantos tipos? En lugar de eso, Java simplemente puede seguir un diseño simple (solo intentar / atrapar todos los tipos) para manejar una condición anormal en un programa.

Answer 1

Diferencia entre excepciones marcadas y no verificadas:

Tenemos muchas diferencias entre la excepción marcada y no verificada, pero todas las diferencias se originan a partir de una consideración básica de que si la excepción es solucionable por el compilador o no.

Los puntos a recordar son:

[1] Excepción marcada significa Compilador revisado Excepciones . Significa que el compilador ordena que dicha excepción sea manejada por el bloque try-catch o lance una palabra clave.

[2] Las excepciones no verificadas son aquellas para las que el compilador no proporciona ningún mandato, ya que el desarrollador puede resolverlas mediante la codificación / programación, ya que el flujo de control es controlable, como en ArithmeticException, NullPointerException ArrayIndexOutOfBoundsException, IllegalArgumentException, etc.

Lo llamo "Prueba de identidad de excepción", en donde tomas cualquier excepción aleatoria de java doc y solo le haces una pregunta. "Hey Exception! ¿Se puede resolver programáticamente?

Si la excepción dice SÍ , se trata de una Excepción no verificada, ya que esto puede resolverse mediante un cambio de código o resolviendo algún error de cálculo, etc.

Por otro lado, si la excepción dice No , se verifica Excepción, ya que en el flujo de control de Excepción comprobado se sale de nuestro código, como si alguien cambia las contraseñas de la Base de datos o alguien desconecta el cable de la red, el tiempo de espera de conexión (ConnectException), no se encuentra algún recurso ( FileNotFoundException, ClassNotFound), SQLException, InvocatonTargetException, etc. Estos no se pueden resolver mediante la programación

Answer 2

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

Answer 3

Throwable está en la parte superior de todas las excepciones. Debajo de Throwable tienes error y excepción. Debajo de la excepción tiene RuntimeException.

Java tiene dos tipos de excepciones: activada y desactivada. El compilador aplica las excepciones comprobadas (tiene que declararlas en la cláusula de lanzamientos y atraparlas eventualmente). Las excepciones no verificadas no se aplican para capturar o declarar en cláusulas de lanzamientos.

(Parte controvertida de la respuesta)

Throwable existe para que haya un padre para todos los tipos de excepción. Nunca debe declarar que lanza Throwable y nunca lo atrapa (a menos que realmente sepa realmente lo que está haciendo).

Existe un error para indicar problemas con el entorno de ejecución, cosas de las que su programa probablemente no se puede recuperar, como un archivo de clase con formato incorrecto o la VM que se está quedando sin memoria. No debe detectar un error a menos que realmente sepa lo que está haciendo.

Existe una excepción como raíz para todos los errores que no son programadores (consulte la excepción RuntimeException para obtener la "excepción"), ya que no se puede crear un archivo porque el disco está lleno. No debes lanzar, tirar, o atrapar Excepción. Si tiene que atrapar la excepción, asegúrese de saber lo que está haciendo.

RuntimeException existe para indicar todos los errores del programador, como pasar del final de una matriz o llamar a un método en un objeto nulo. Estas son cosas que debe arreglar para que no hagan excepciones, lo que indica que usted, el programador, cometió un error en el código. Nuevamente, no debes atraparlos a menos que sepas lo que estás haciendo.

Answer 4

La respuesta de TofuBeer explica claramente qué significan las clases de excepción.

¿Por qué estos muchos tipos? En lugar de eso, Java simplemente puede seguir un diseño simple (solo intentar / atrapar todos los tipos) para manejar una condición anormal en un programa.

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

• ¿Cómo atraparía "todos los errores fatales de JVM" sin la clase Error ?
• ¿Cómo capturaría "todas las excepciones que no son errores fatales de JVM" sin la clase Exception ?
• ¿Cómo atraparía "todas las excepciones no verificadas" sin la clase RuntimeException ?

Answer 5

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

[Imagen cortesía de JavaTpoint ].

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

Excepción comprobada:

• Estas son las clases que extienden Throwable excepto RuntimeException y Error .
• También se conocen como excepciones de tiempo de compilación porque se verifican en el momento de la compilación, lo que significa que el compilador nos obliga a manejarlas con try/catch o indicar en la firma de función que las throws y obligándonos a tratarlas en la persona que llama.
• Son problemas recuperables de manera programática 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 no marcada:

• Las clases que extienden RuntimeException se conocen como excepciones no verificadas.
• Las excepciones no marcadas 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 la excepción comprobada, se deben a fallas en el flujo o la configuración del código.
• Ejemplo: ArithmeticException , NullPointerException , ArrayIndexOutOfBoundsException , etc.
• Ya que son errores de programación, pueden evitarse codificando bien / sabiamente. Por ejemplo, "dividir por cero" produce una ArithmeticException , que se puede evitar con una simple comprobación del divisor. De manera similar, podemos evitar NullPointerException simplemente verificando las referencias: if (object != null) o incluso usando mejores técnicas .

Error:

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

¿Por qué son estos muchos tipos?

Además de la respuesta de Stephen C , quiero decir: el manejo de excepciones es una operación relativamente costosa en Java. No debemos 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, las Exception deben manejarse programáticamente siempre que sea posible. Por otro lado, no podemos manejar los Error s, por lo que estas pueden ser algunas razones lógicas por las que hay muchos tipos de excepciones.

Answer 6

• Error (los lanzamientos por VM, no deben ser capturados o manejados)
  1. Error de VM
  2. Error de aserción
  3. Error de vinculación ... y así sucesivamente
• Runtime / Uncheck Exception (error de programación, no debe ser capturado o manejado)
  1. Excepción de puntero nulo
  2. ArrayIndexOutOfBoundException
  3. IllegalArgumentException ... así sucesivamente
• Verifique la excepción (todo lo demás, se espera que las aplicaciones se detecten o manejen)
  1. IOException
  2. FileNotFoundException
  3. SQLException ... así sucesivamente