(I) Jerarquía de excepción de Java
Para comprender la diferencia entre la excepción verificada y la excepción sin control en Java, veamos primero la jerarquía de excepción de Java.
Este es un diagrama de jerarquía de excepción de Java simplificado. Cabe señalar que todas las clases se heredan de lanzamiento, y la siguiente capa se divide en dos estructuras, error y excepción. El nivel de clase de error describe errores internos y errores de agotamiento de recursos en el sistema de tiempo de ejecución Java. Además de simplemente informar este error al usuario e intentar evitar que el programa se termine de manera segura, generalmente hay otras soluciones.
(Ii) la diferencia entre la excepción sin control y la excepción verificada
Después de comprender lo anterior, echemos un vistazo a lo que se verifica la excepción y lo que es una excepción sin control. De hecho, la especificación del idioma Java define estos dos muy simples. Las excepciones derivadas de Error o RuntimeException se denominan excepciones no marcadas, y todas las demás excepciones se vuelven verificadas excepciones . Aunque esta definición es muy simple, RuntimeException es un concepto muy confuso. Parece que todas nuestras excepciones están en el proceso de ejecutar el programa. Mi explicación de RU nTimeException en Java efectiva no es tan satisfactoria.
Use excepciones verificadas para condiciones recuperables y excepciones de tiempo de ejecución para errores de programación (elemento 58 en la segunda edición)
Sin embargo, a partir de esta oración, simplemente podemos extenderla, es decir, si ocurre una RuntimeException, debe ser un problema para el mismo programador. Por ejemplo, los subíndices de matriz están fuera de los límites y acceden a las excepciones de puntero nulo, etc. Siempre que preste un poco de atención, estas excepciones son excepciones que se pueden evitar en la etapa de codificación. Si todavía cree que estos dos conceptos son difíciles de distinguir, entonces el método "más violento" es memorizar la Corriente RuntimeException, que puede ahorrar mucho tiempo para juzgar.
(Iii) ¿Por qué debemos distinguir entre excepciones sin control y excepciones verificadas?
La razón es en realidad muy simple. El compilador verificará si proporciona un mecanismo de manejo de excepciones para todas las excepciones verificadas. Por ejemplo, cuando usamos class.forname () para encontrar el objeto de clase de una cadena dada, si no se proporciona el manejo de excepciones para este método, la compilación no se pasará.
(Iv) ¿Qué excepciones debemos declarar?
Como dijimos anteriormente, RuntimeException es un error que se puede evitar durante el proceso de programación. Entonces, ¿no necesitamos lanzar estas excepciones? En principio, esto es cierto, pero la especificación de Java no limita esto. Parece que arrojas una matriz de límites y no hay un significado práctico, y por el contrario, causará ciertas pérdidas de rendimiento. Entonces, ¿cómo debemos diseñar excepciones? Necesitamos recordar que las siguientes dos situaciones son necesarias para declarar excepciones de lanzamiento:
Llame a un método de excepción verificada, como IOException. En cuanto a la razón, hemos discutido anteriormente, si se lanzan todas las excepciones verificadas, no se puede compilar. Se encontró un error durante el programa en funcionamiento y se lanzó una excepción utilizando la declaración de lanzamiento. Para excepciones sin control, solo hay dos situaciones principales: evitables (excepción de tiempo de ejecución) o incontrolable. Estos también requieren declaración de excepciones.
Aquí hay ejemplos para ilustrar las cosas incómodas mencionadas en la nota 2 arriba:
Primero, defina una clase de excepción básica GenericException, heredada de la excepción.
paquete check_unchecked_excepciones; public class GenericException extiende la excepción { / ** * * / private Static final Long SerialVersionUid = 2778045265121433720l; public GenericeException () {} public GenericException (String Msg) {super (msg); }} A continuación se define una clase de prueba VerifyException.
paquete check_unchecked_excepciones; clase pública VerifyException {public void First () lanza GenericException {Throw New GenericeException ("Excepción verificada"); } public void Second (String msg) {if (msg == null) {lanzar nueva nullpointerException ("excepción sin control"); }} public void Third () lanza GenericException {First (); } public static void main (string [] args) {verifyException ve = new VerifyException (); intente {ve.first (); } catch (genericException e) {E.PrintStackTrace (); } ve.second (nulo); }}Después de correr, obtenga la siguiente información sobre la consola de Eclipse:
check_unchecked_exceptions.GenericException: excepción verificada
en check_unchecked_exceptions.verifyException.first (VerifyException.java:6)
en check_unchecked_exceptions.verifyException.main (VerifyException.java:23)
Excepción en el hilo "principal" java.lang.nullpointerexception: excepción sin control
en check_unchecked_exceptions.verifyException.second (verifyException.java:11)
en check_unchecked_exceptions.verifyException.main (verifyException.java:29)
En el ejemplo anterior, combinados con los conceptos de controlado y sin control, se puede ver que la excepción de la clase principal es de tipo verificado, pero su subclase RuntimeException (subclase nullpointerexception) no está marcado.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.