1. Descripción general
Existe la clave de afirmación en los lenguajes C y C++, que significa afirmación.
En Java, también existe la palabra clave afirmar, que significa afirmación. El uso y el significado son similares.
2. gramática
En Java, la palabra clave de aserción se introdujo desde JAVA SE 1.4. Para evitar errores causados por el uso de la palabra clave de aserción en versiones anteriores del código Java, Java no habilita la verificación de aserciones de forma predeterminada durante la ejecución (en este momento, todas las declaraciones de aserción lo harán). ¡ser ignorado!), si desea habilitar la verificación de aserciones, debe activarla con el modificador -enableassertions o -ea.
La sintaxis de la palabra clave afirmar es muy simple y tiene dos usos:
1. afirmar <expresión booleana>
Si <expresión booleana> es verdadera, la ejecución del programa continúa.
Si es falso, el programa arroja un AssertionError y finaliza la ejecución.
2. afirmar <expresión booleana>: <expresión de mensaje de error>
Si <expresión booleana> es verdadera, la ejecución del programa continúa.
Si es falso, el programa arroja java.lang.AssertionError e ingresa <expresión de mensaje de error>.
3. Ejemplos de aplicación
A continuación se proporciona un ejemplo para ilustrar su uso:
Copie el código de código de la siguiente manera:
clase pública AssertFoo {
público estático vacío principal (String args []) {
// El resultado de la afirmación 1 es verdadero, luego continúa la ejecución.
afirmar verdadero;
System.out.println("No hay problema con la afirmación 1, ¡adelante!");
System.out.println("/n-----------------/n");
//El resultado de la afirmación 2 es falso y el programa termina
afirmar falso: "¡La afirmación falló, la información de esta expresión se generará cuando se produzca una excepción!";
System.out.println("No hay problema con la afirmación 2, ¡adelante!");
}
}
Guarde el código en C:/AssertFoo.java, luego ejecútelo de la siguiente manera y vea la salida de la consola:
1. Compile el programa:
C:/>javac AssertFoo.java
2. El programa se ejecuta de forma predeterminada sin activar el modificador -ea:
C:/>java AssertFoo
La afirmación 1 está bien, ¡adelante!
------------------
La afirmación 2 no es un problema, ¡adelante!
3. Active el modificador -ea y ejecute el programa:
C:/>java -ea AssertFoo
La afirmación 1 está bien, ¡adelante!
------------------
Excepción en el hilo "principal" java.lang.AssertionError: la aserción falló, la información de esta expresión
¡Se generará cuando se produzca una excepción!
en AssertFoo.main(AssertFoo.java:10)
4. Trampa
La palabra clave afirmar es fácil de usar, pero usar afirmar a menudo te hará caer en una trampa cada vez más profunda. Debe evitarse. Después de la investigación, el autor resumió las siguientes razones:
1. La palabra clave afirmar debe habilitarse explícitamente en tiempo de ejecución para que surta efecto; de lo contrario, su afirmación no tendrá sentido. Actualmente, las principales herramientas IDE de Java no habilitan la función de verificación de aserciones -ea de forma predeterminada. Esto significa que si utiliza herramientas IDE para codificar, tendrá algunos problemas al depurar y ejecutar. Además, para las aplicaciones web Java, el código del programa se implementa en el contenedor y no puede controlar directamente la ejecución del programa. Si debe activar el modificador -ea, debe cambiar los parámetros de configuración de ejecución del contenedor web. Esto trae grandes inconvenientes para el trasplante y el despliegue de programas.
2. Usar afirmar en lugar de si es la segunda trampa. El juicio de afirmar es similar al de la declaración if, pero las funciones de los dos son esencialmente diferentes: la palabra clave afirmar está destinada a usarse al probar y depurar el programa, pero si accidentalmente usa afirmar para controlar el proceso de negocios del programa, no se utilizará durante las pruebas y depuración. Eliminar la palabra clave afirmar una vez finalizado significa modificar la lógica normal del programa.
3. Si la afirmación falla, el programa saldrá. Esto nunca se toleraría en un entorno de producción. Los errores potenciales en el programa generalmente se resuelven mediante el manejo de excepciones. Pero el uso de afirmaciones es muy peligroso. Una vez que falla, el sistema se bloqueará.
5. Reflexiones sobre afirmar
Dado que afirmar es para depurar programas de prueba y no para su uso en entornos de producción formales, debería considerar probar mejor JUint para reemplazar su función. JUint proporciona incluso más funciones clave que afirmar. Por supuesto, la depuración y las pruebas se pueden realizar mediante la depuración IDE. Desde este punto de vista, el futuro de la afirmación es sombrío.
Por lo tanto, debe evitar el uso de la palabra clave afirmar en Java, a menos que un día Java admita el modificador -ea de forma predeterminada, entonces podrá considerarlo. Compare cuántos beneficios y cuántos problemas puede traerle afirmar. Este es el principio para que elijamos si lo utilizamos.
==================================================== ==========
comentario:
Por otro lado, en algunos componentes de código abierto, como validador y junit, el proceso de juicio parece utilizar un estilo de afirmación. Es muy probable que se utilice una gran cantidad de afirmaciones, pero el autor no puede estar seguro antes de mirarlas. código fuente.
Si se trata de una prueba sencilla durante la fase de desarrollo, junit es una herramienta cómoda y poderosa. No hay razón para no utilizarla al escribir sus propias afirmaciones.
==================================================== ==========
comentario:
Primero, se puede utilizar en el código de prueba unitaria. Junit es muy intrusivo. Si una gran cantidad de código en todo el proyecto usa Junit, será difícil eliminarlo o elegir otro marco. Si hay muchos códigos de prueba unitaria y desea reutilizar estos casos de prueba unitaria, debe elegir afirmar en lugar de junit para facilitar el uso de otros marcos de prueba unitaria, como TestNG. Por la misma razón, Junit no debería aparecer en absoluto en el código funcional formal y se debería utilizar afirmar.
afirmar es principalmente adecuado para clases base, clases marco, clases de interfaz, clases de código central y clases de herramientas. En otras palabras, es necesario usarlo cuando la persona que llama a su código es un código comercial escrito por otro programador u otro subsistema. Por ejemplo, si crea un algoritmo de clasificación rápida
Copie el código de código de la siguiente manera:
Lista estática pública <int> clasificación rápida (Lista <int> lista) {
lista de afirmación! = nulo;
//Solicitar espacio temporal
//Comenzar a ordenar
para(int i: lista){
//
}
}
En este caso, si no se verifica la exactitud de los parámetros entrantes, se generará un error de puntero nulo inexplicable. Es posible que las personas que llaman no conozcan los detalles de su código y depurar un error de puntero nulo en lo profundo de un sistema es una pérdida de tiempo. Debe decirle directa y claramente a la persona que llama que hay un problema con los parámetros pasados. De lo contrario, sospechará que su código tiene un ERROR. El uso de afirmar puede evitar que dos programadores se culpen mutuamente por problemas con el código que escribieron.
afirmar se aplica a errores en los que usted sabe exactamente cuál es el error y usted y la persona que llama han acordado que la persona que llama debe eliminarlos o verificar si hay errores. Se lo dice a la persona que llama mediante una afirmación. afirmar no se aplica a errores causados por sistemas externos, como errores en los datos de entrada del usuario o errores de formato en un archivo externo. Estos errores no son causados por la persona que llama sino por el usuario, y ni siquiera son excepciones, porque los errores de entrada y los errores de formato de archivo son comunes, y estos errores deben ser verificados por el código comercial.
afirmar es más adecuado para clases base, código de marco, clases de herramientas, código central y código de interfaz llamados con frecuencia. Es por eso que se elimina en tiempo de ejecución. El código de prueba debe habilitar el parámetro -ea durante la fase de prueba para facilitar la prueba cuidadosa del código central en lo profundo del sistema.
La razón por la que Java usa aserción con menos frecuencia es que Java tiene un sistema OO muy completo y la conversión de tipo forzada ocurre con menos frecuencia, por lo que no es necesario verificar con frecuencia si el tipo del puntero es correcto y si el puntero está vacío como C. Al mismo tiempo, Java rara vez administra la memoria o los buffers directamente, por lo que no es necesario verificar con frecuencia si el buffer entrante está vacío o ha cruzado el límite.
Pero usar asertar bien puede ayudar a mejorar la corrección del código marco y reducir el tiempo de depuración de los usuarios del código marco.
==================================================== ==============
comentario:
El propósito de afirmar es permitir a los programadores descubrir fácilmente sus propios errores lógicos sin afectar la eficiencia del programa. Los errores encontrados por afirmar no deberían ocurrir en absoluto y no pueden ser reemplazados por excepciones. Las excepciones son permitidas por el sistema, o son "errores" que son incontrolables por el sistema. No son problemas lógicos del programador.
La afirmación debe activarse durante el desarrollo y desactivarse después del lanzamiento.