Mecanismo de manejo de excepciones-Excepción
Java nos proporciona un mecanismo completo de manejo de excepciones, lo que nos permite centrarnos más en escribir programas. A veces, cuando encontramos un lugar donde necesitamos agregar un bloque de manejo de excepciones, como eclipse, te lo recordaremos automáticamente y ¡te sentirás muy feliz! Veamos la estructura de algunas clases de manejo de excepciones.
Fundamentalmente divididos en dos categorías: errores y errores de excepción, que son errores que el programa no puede manejar, como OutOfMemoryError ThreadDeath. Cuando ocurren estas excepciones, la Máquina Virtual Java (JVM) generalmente elige terminar el hilo. Las excepciones son excepciones que el propio programa puede manejar. Dichas excepciones se dividen en dos categorías: excepciones que no son de tiempo de ejecución (que ocurren durante la fase de compilación, también llamadas checkException) y excepciones de tiempo de ejecución (también llamadas uncheckException). Las excepciones que no son de tiempo de ejecución generalmente se refieren a excepciones que son fáciles de ver y resolver cuando el código no cumple con las especificaciones del lenguaje Java. Las excepciones de tiempo de ejecución son excepciones que ocurren durante la ejecución del programa, como excepciones de puntero nulo, que se deben a diversas razones. La incertidumbre de las excepciones en tiempo de ejecución a menudo es difícil de encontrar y también hay errores lógicos en el programa. Los errores que solo se pueden descubrir observando la situación general también pueden causar excepciones en tiempo de ejecución, lo que requiere que prestemos la mayor atención posible al manejo de excepciones al escribir programas. Cuando ocurre una excepción, espero que el programa se ejecute en la dirección ideal.
Dos tipos de excepciones
Por un lado, podemos dividir las excepciones en excepciones controladas y excepciones no controladas. De hecho, en términos generales, las excepciones controladas son excepciones que no son de tiempo de ejecución y las excepciones no controladas son excepciones y errores de tiempo de ejecución. Por otro lado, dividimos directamente las excepciones en excepciones que no son de tiempo de ejecución y excepciones de tiempo de ejecución.
Proceso de manejo de excepciones
Utilice el bloque de declaración try/catch/finally para instalar el controlador de excepciones. Cada bloque try contiene declaraciones que pueden causar una excepción y cada bloque catch contiene procedimientos para manejar excepciones.
Prueba de clase pública {
Public static void main(String[] args) {
string filename = d:\\test txt;
Pruebe {
FileReader lector=nuevo lector de archivos (nombre de archivo)
Entrada del escáner=nuevo escáner(lector)
Entrada de cadena = en siguiente()
int value = Entero parseInt(entrada)
Salida del sistema print(valor)
} catch(archivo no encontrado excepción e) {
e printStackTrace()
}Finalmente {
Salida del sistema println (¡esto finalmente es un bloque!)
}
}
}
Si no hay ningún texto de prueba en el directorio raíz del disco d, el programa generará una excepción
¡Esta vez finalmente se bloquea!
Excepción de archivo Java io no encontrado: d:\testtxt (El sistema no puede encontrar el archivo especificado).
Cuando se abre el flujo de entrada del archivo java io (método nativo)
En el flujo de entrada del archivo java io ltinit gt (flujo de entrada de archivo java:)
En flujo de entrada de archivos java io ltinit gt(flujo de entrada de archivos java:)
En java io FileReader ltinit gt(lector de archivos java:)
En prueba principal(prueba java:)
Sin embargo, la declaración en el bloque finalmente genera esto temporalmente. Recuerde crear un nuevo archivo txt de prueba en la unidad D e ingresar el contenido antes de observar.
Salida
¡Esta vez finalmente está bloqueada!
Las declaraciones en el bloque finalmente aún se generan, lo que significa que las declaraciones en el bloque finalmente se ejecutarán independientemente de si el programa es anormal, por lo que generalmente hay algunas declaraciones que cierran los recursos en el bloque finalmente. bloquear. A continuación, continuamos el experimento. Cambiemos el texto de prueba a abc y veamos los resultados.
¡Por fin está bloqueado!
Se produjo una excepción en el hilo principal del lenguaje Java NumberFormatException: de la cadena de entrada abc
en Java lang NumberFormatException para la cadena de entrada(NumberFormatException Java:)
en Java lang Integer parse int(Integer Java:)
en Java lang Integer parse int(Integer Java:)
Probando main(probando java:)
Soy En esta excepción se marcan dos puntos importantes. Uno es la excepción roja en el hilo principal, que indica la ubicación donde se lanza la excepción. El otro es la excepción en formato de número de idioma Java: para la cadena de entrada: ABC, que indica el tipo de excepción. Aquí, echemos un vistazo a por qué el resultado anterior no arrojó una excepción. Al observar detenidamente el programa fuente, descubrí que NumberFormatException no se declaró explícitamente en el programa, pero sí se declaró FileNotFoundException. Para resumir aquí, es decir, si declaro una excepción en el programa, no la arrojaré directamente. Si no lo declaro en el programa, el programa arrojará la fuente de la excepción al mismo tiempo. ¿Por qué? ¿Qué hace el sistema cuando no lo declaro explícitamente? Definitivamente hay un patrón. Sigamos experimentando.
[java]
Prueba de clase pública {
Public static void main(String[] args) {
string filename = d :\\test txt;
//captura de excepción
prueba {
lector FileReader = nuevo lector de archivos (nombre de archivo)
Entrada del escáner = nuevo escáner (lector)
Entrada de cadena = en siguiente()
valor int = entero parseInt(entrada)
Salida del sistema imprimir(valor)
} catch(excepción de archivo no encontrado e){//Captura la excepción de archivo no encontrado.
e printStackTrace()
} catch(NumberFormatException e){//NumberFormatException
E printStackTrace() //Imprimir la información de la excepción está en el idioma java NumberFor… ...
Salida del sistema println (¡Estoy aquí!)
}Finalmente {
Salida del sistema println (¡Esto finalmente es un bloque!)
}
}
}
Agregué un bloque catch para capturar la excepción NumberFormatException y la salida del programa.
NumberFormatException del lenguaje Java: para cadena de entrada: abc
en Java lang NumberFormatException para cadena de entrada(NumberFormatException Java:)
en Java lang Integer parse int( Integer Java:)
en Java idioma Integer parse int(Integer Java:)
Probando main(probando java:)
¡Estoy aquí!
¡Por fin está bloqueado!
Continúe modificando el código donde no se genera ninguna excepción de salida.
[java]
Prueba de clase pública{
public void open(){
nombre de archivo de cadena = d:\\test txt ;
Pruebe {
lector FileReader=nuevo lector de archivos(nombre de archivo)
Entrada del escáner=nuevo escáner(lector)
Entrada de cadena = in next()
int value = Entero parseInt(entrada)
Salida del sistema print(valor)
} catch(archivo no encontrado excepción e){
e printStackTrace()
Salida del sistema println (¡este es un bloque de prueba!)
}
}
}
[java]
Prueba de clase pública{
Carril vacío público(){
Prueba t = nueva prueba( )
intenta {
t open()
} catch(Exception e) {
e printStackTrace()
Salida del sistema println (¡este es un bloque de prueba!)
}
}
}
[ java]
Prueba de clase pública {
Public static void main(String[] args) {
Prueba t = new test()
tCarry( )
}
}
La idea es que la clase de prueba maneje el negocio, la clase de prueba llame al método abierto de la clase de prueba y finalmente en la clase de prueba Se llama al método de acarreo de la clase de prueba, pero lanzo una excepción durante la prueba y veo el resultado de la salida de la excepción.
lenguaje Java NumberFormatException: para cadena de entrada: abc
en Java lang NumberFormatException para cadena de entrada(NumberFormatException Java:)
en Java lang Integer parse int( Integer Java:)
en Java lang Integer parse int(Integer Java:)
Al probar open (test java:)
Al probar carry (test java:) )
Probando main(testing java:)
¡Este es un bloque de prueba!
La excepción lanzada primero no tiene información local y luego el resultado es un bloque de prueba. Explicación La excepción fue lanzada desde el método de acarreo de la clase de prueba.
Cuando comentamos la declaración de captura de excepción en la clase de prueba, la excepción es la siguiente.
Se produjo una excepción en el hilo principal del lenguaje Java NumberFormatException: de la cadena de entrada abc
en Java lang NumberFormatException para la cadena de entrada(NumberFormatException Java:)
en Java lang Integer parse int(Integer Java:)
en Java lang Integer parse int(Integer Java:)
Cuando la prueba está activada (test java:)
Prueba de acarreo Cuando (probando java:)
Al probar main (probando java:)
Al ver esto, creo que los lectores deberían tener ciertos sentimientos. Digo todo esto sólo para explicar lo que sucede cuando un programa no puede manejar una excepción. La cuestión es esta: si el controlador de excepciones correspondiente se declara en el método actual, como el programa anterior, si se agrega catch (NumberFormatException e), se lanzará directamente, pero si no se declara, se encontrará a la persona que llama Si se llama Si el operador no realiza el procesamiento correspondiente, seguirá buscando hasta encontrar el método principal y finalmente arroja una excepción, por lo que el fenómeno anterior no es difícil de explicar. Aquí hay un breve resumen del proceso de manejo de excepciones. Agregue una declaración de bloque try/catch para llamar al controlador de excepciones cuando ocurre una excepción. Si hay una excepción, lanza una excepción y ejecuta la declaración en el bloque catch. Si no hay yo, se encuentra su llamador hasta que el método principal ejecuta las declaraciones en el bloque finalmente (si hay un bloque finalmente).
Nota
Un intento puede corresponder a múltiples capturas. Debe haber al menos un bloque catch finalmente, no es obligatorio ni opcional. Normalmente, cuando ocurre una excepción, se ejecutarán las declaraciones en el bloque catch. En el caso especial, cuando se lanza una excepción en el método principal, si el programa declara un controlador de excepciones, se ejecutarán las declaraciones en el bloque catch correspondiente. Si el programa no declara un controlador de excepciones correspondiente, las declaraciones en el bloque catch no se ejecutarán y se lanzará una excepción directamente. Entonces, ¿de dónde viene esta anomalía? Dado que hay una declaración try/catch en el método principal (aunque no es un controlador de excepciones correspondiente), ¿por qué no se lanza? En otras palabras, el bloque try/catch en el método principal no detecta la excepción en absoluto. ¿El sistema lo maneja? En realidad, en este caso, la excepción se lanza directamente a la JVM, que la maneja interrumpiendo su programa directamente. Es así de simple
Cuatro excepciones comunes
Excepción de puntero nulo
Se genera una excepción de puntero nulo cuando la aplicación intenta usar Null cuando se requiere un objeto, como as Llame al método de instancia del objeto nulo para acceder a las propiedades del objeto nulo, calcule la longitud del objeto nulo, use la declaración de lanzamiento para arrojar nulo, etc.
¿ClassNotFoundException? Clase no encontrada.
Excepción de clase no encontrada Esta excepción se produce cuando una aplicación intenta construir una clase basada en un nombre de clase en forma de cadena y después de recorrer CLASSPAH no puede encontrar un archivo de clase con el nombre correspondiente.
Conversión de tipo ClassCastException
Condición aritmética de excepción aritmética
Condición aritmética de excepción, como división de enteros por cero, etc.
¿ArrayIndexOutOfBoundsException? Matriz fuera de límites
Cuando el valor del índice de la matriz es negativo o mayor o igual que el tamaño de la matriz, se generará una excepción de índice de matriz fuera de límites.
Continuaremos actualizando este contenido. Se solicita a los lectores que sigan planteando sus propias anomalías significativas mientras leen y continúen enriqueciendo la publicación del blog. ¡Los lectores pueden agregar activamente!
Si tienes alguna duda, ponte en contacto con egg.
5 Excepciones y Errores
Excepciones en Java, los errores en un programa son principalmente errores de sintaxis y errores semánticos. Los llamamos colectivamente excepciones. Es una forma de que la JVM (Java Virtual Machine) le notifique un error. Ahora existe la posibilidad de revisarlo. En Java, diferentes clases de excepción representan diferentes excepciones, pero en Java, todas las excepciones tienen una clase base llamada excepción.
Los errores son problemas graves que no pueden ser interceptados por una aplicación razonable. La mayoría son situaciones anormales. El error es un problema de JVM (aunque puede ser cualquier servicio a nivel de sistema), por lo que es difícil lidiar con errores, que es algo que los desarrolladores comunes no pueden manejar, como el desbordamiento de memoria.
Seis afirmaciones (aserciones)
Assert es una nueva característica compatible con jdk, que se habilita principalmente durante el desarrollo y las pruebas. Para garantizar el rendimiento, las afirmaciones de habilitación generalmente se desactivan después del lanzamiento oficial del programa. Configurar ea o enableassertions en los parámetros de inicio es relativamente simple.
Hay dos situaciones para las expresiones de aserción.
) En este momento afirmar exp exp es una expresión booleana.
Cuando su valor es verdadero se ejecutará, si es falso arrojará el AssertionError correspondiente. Se puede captar la atención.
)assert exp: exp En este momento, exp es el mismo que el anterior. exp puede ser un tipo básico o un objeto. Cuando el valor de exp es verdadero, igual que el anterior, no se calculará exp. Cuando exp se evalúa como falso, se genera un AssertionError y el resultado de exp se usa como parámetro en el constructor AssertionError. Al detectar este error, puede utilizar el método getMessage() para generar el resultado de exp.
Al usar aserciones, tenga en cuenta que las aserciones son solo una herramienta para depurar el programa y no deben usarse como parte del programa o alguien usa aserciones en lugar de try/catch. Esto es lo contrario de lo que hacen las afirmaciones. La afirmación se cerrará después de que se publique el programa. Si se utilizan como parte de un programa, inevitablemente ocurrirán problemas con el programa cuando se desactiven las aserciones. Hay mejores formas, como intentar/capturar. ¿Por qué seguir usando afirmaciones? Por eso es mejor no hablar de afirmaciones como parte de un programa. Puedes considerarlos prescindibles desde el fondo de tu corazón.
Siete preguntas frecuentes
Finalmente está el tema de las devoluciones
Solemos decir que el contenido finalmente se ejecutará independientemente de si el programa es anormal Entonces, si nuestro programa es ¿Se ejecutará si finalmente se devuelve en los bloques try y catch? Los lectores pueden adivinar y analizar primero, y luego haremos experimentos.
[java]
Prueba final de clase pública {
Public static void main(String[] args) {
archivo booleano = open()
Salida del sistema println (este es el valor de retorno principal: archivo)
}
Booleano estático público open() {
cadena nombre de archivo = d:\\test txtp;
pruebe {
lector FileReader=nuevo FileReader(nombre de archivo)
entrada del escáner=nuevo escáner (lector )
Entrada de cadena = in next()
valor int = entero parseInt(entrada)
Salida del sistema print(valor)
Devuelve verdadero
} catch(excepción de archivo no encontrado e){
Salida del sistema println (¡este es el bloque catch_for_filenot...!)
Devuelve falso
}Finalmente {
Salida del sistema println (¡esto finalmente es un bloque!)
}
}
}
Escriba mal intencionalmente el nombre del archivo para crear la siguiente salida de excepción
¡Este es el bloque catch_for_filenot...!
¡Por fin está bloqueado!
Este es el valor de retorno principal: false
Como se puede ver desde aquí, el programa primero genera el contenido en el bloque catch y luego ejecuta el contenido en el método principal que finalmente se ejecuta. Aunque el resultado de false indica que el contenido del bloque catch se ha devuelto correctamente, definitivamente podemos responder a la pregunta de que el bloque finalmente se ejecutará incluso si hay una declaración de devolución.
Intenta no utilizar catch y finalmente juntos.
Utilice try/catch/finally juntos como el programa que demostré arriba. En el libro "Big Java" se menciona que esto no se recomienda porque afectará la legibilidad del programa. La mejor manera es utilizar capturas anidadas try/catch para detectar excepciones y, finalmente, cerrar el recurso. Modificar de la siguiente manera
[java]
Prueba final de clase pública {
Public static void main(String[] args) {
boolean file = open()
Salida del sistema println (este es el valor de retorno principal: file)
}
Public static boolean open() {
cadena nombre de archivo = d:\\test txtp;
prueba {
prueba{
lector FileReader = nuevo lector de archivos (nombre de archivo)
Entrada del escáner = nuevo escáner(lector)
Entrada de cadena = en next()
valor int = entero parseInt(entrada)
Salida del sistema print(value)
Devuelve verdadero
}Finalmente {
//Algunas operaciones para cerrar recursos.
Salida del sistema println (¡esto finalmente es un bloque!)
}
} catch(excepción de archivo no encontrado e){
Salida del sistema println (¡esto es catch_for_filenot... bloque!)
Devuelve falso
}
}
}
Excepción personalizada
Después de todo, el propio controlador de excepciones del sistema no puede satisfacer todas las necesidades, porque para nosotros, los desarrolladores, cuanto más detallada sea la excepción, más fácil nos resultará encontrar problemas. ¿No podemos lanzar excepciones para todos los problemas? Demasiado generales. En el desarrollo real, podemos personalizar el controlador de excepciones según nuestras propias necesidades.
[java]
/**
* Los controladores de excepciones personalizados heredan Exception o RuntimeException según las circunstancias específicas.
* @author青儿
*
*/
La clase pública NameNotSupportException extiende RuntimeException {
privada static final long serialVersionUID = L;
public NameNotSupportException(){
}
Public NameNotSupportException(mensaje de cadena){
super( mensaje)
}
}
[java]
Prueba de definición de clase pública{
Vacío estático público main(String[] args) {
String nombre = huevo
If (! 青儿 es igual a (nombre)) {
Lanzar nueva NameNotSupportException (Qing' er)
} De lo contrario {
Salida del sistema println (¡el nombre está bien!)
}
}
}
[java]
Se produjo una excepción en el hilo principal NameNotSupportException: Qing'er
Lishi Xinzhi/Article/program/Java/hx/201311 /25806