Saltar al contenido

Diferencias entre Runtime/Checked/Unchecked/Error/Exception

Comprende el código bien antes de aplicarlo a tu trabajo si ttienes algo que aportar puedes dejarlo en la sección de comentarios.

Solución:

Throwable está en la parte superior de todas las excepciones. Debajo de Throwable tienes Error y Exception. Debajo de Exception tiene RuntimeException.

Java tiene dos tipos de excepciones: marcadas y no marcadas. El compilador hace cumplir las excepciones comprobadas (debe declararlas en la cláusula throws y atraparlas eventualmente). Las excepciones no verificadas no se aplican para capturar 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 lanzas Throwable y nunca lo atrapas (a menos que realmente sepas lo que estás haciendo).

El error existe para indicar problemas con el entorno de tiempo de ejecución, cosas de las que su programa probablemente no pueda recuperarse, como un archivo de clase mal formateado o la máquina virtual 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 del programador (consulte RuntimeException para conocer la “excepción” a esto), como que no se puede crear un archivo porque el disco está lleno. No debe lanzar, lanzar o atrapar excepciones. Si tiene que atrapar una excepción, asegúrese de saber lo que está haciendo.

RuntimeException existe para indicar todos los errores del programador, como pasar el final de un array o llamando a un método en un null objeto. Estas son cosas que debes arreglar para que no arrojen excepciones – indican que tú, el programador, estropeaste el código. Una vez más, no debe atraparlos a menos que sepa lo que está haciendo.

Dado que 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 Throwable jerarquía de clases:
Jerarquía de clases arrojables

[image courtesy of JavaTpoint].

Hay tres key Clases para recordar aquí: Throwable, Exception y Error. Entre estas clases Exception se puede dividir en dos tipos: “Excepción comprobada” y “Excepción no comprobada”.

Excepción marcada:

  • Estas son las clases que se 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 la función que throws ellos y obligándonos a tratar con ellos en la llamada.
  • 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, SQLExceptionetc

Excepción no verificada:

  • Las clases que se extienden RuntimeException se conocen como excepciones no comprobadas.
  • Las excepciones no verificadas no se verifican en tiempo de compilación, sino en tiempo de ejecución, de ahí el nombre.
  • También son problemas recuperables programáticamente, pero a diferencia de excepción comprobada son causados ​​por fallas en el flujo de código o en la configuración.
  • Ejemplo:ArithmeticException,NullPointerException, ArrayIndexOutOfBoundsExceptionetc
  • Dado que son errores de programación, se pueden evitar mediante una codificación agradable/sabia. Por ejemplo, “dividir por cero” produce un ArithmeticException, que se puede evitar con una simple comprobación del divisor. Del mismo modo podemos evitar NullPointerException simplemente comprobando las referencias: if (object != null) o incluso utilizando mejores técnicas.

Error:

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

¿Por qué hay tantos tipos?

Además de la respuesta de Stephen C, quiero decir: el manejo de excepciones es una operación relativamente costosa en Java. No deberíamos poner toda situación excepcional en un try/catch cuadra. Uso excesivo de try/catchs pueden obstaculizar el rendimiento del programa.

En conclusión, ExceptionLos correos electrónicos deben manejarse mediante programación siempre que sea posible. Por otro lado, no podemos manejar Errors, por lo que estas podrían ser algunas razones lógicas por las que hay muchos tipos de excepciones.

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

¿Por qué tantos tipos? En cambio, Java puede simplemente seguir un diseño simple (solo intente / capture 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 detectaría “todos los errores fatales de JVM” sin el Error ¿clase?
  • ¿Cómo detectaría “todas las excepciones que no son errores fatales de JVM” sin el Exception ¿clase?
  • ¿Cómo atraparía “todas las excepciones no verificadas” sin el RuntimeException ¿clase?

Si entiendes que ha resultado de provecho nuestro artículo, nos gustaría que lo compartas con otros entusiastas de la programación y nos ayudes a extender nuestro contenido.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *