Saltar al contenido

Excepción Vs Aserción

Después de consultar especialistas en esta materia, programadores de deferentes ramas y profesores dimos con la solución al problema y la plasmamos en esta publicación.

Solución:

Utilice aserciones para verificaciones de lógica interna dentro de su código y excepciones normales para condiciones de error fuera del control inmediato de su código.

No olvide que las afirmaciones se pueden activar y desactivar; si le importan cosas como la validación de argumentos, eso debería ser explícito al usar excepciones. (Sin embargo, puede optar por realizar la validación de argumentos en privado métodos que usan aserciones, con el argumento de que una violación en ese punto se debe a un error interno en lugar de un error externo).

Alternativamente, es completamente razonable (IMO) usar excepciones para todo. Personalmente, no uso mucho las afirmaciones, pero hasta cierto punto es una cuestión de preferencia personal. (Ciertamente puede haber argumentos objetivos a favor y en contra de las afirmaciones, pero no es lo suficientemente claro como para eliminar la preferencia por completo).

Las aserciones de Java se construyen sobre las excepciones de Java y el manejo de excepciones. De hecho, cuando falla una aserción de Java, el resultado es una excepción AssertionError que se puede capturar como cualquier otra excepción de Java. los key Las diferencias entre excepciones y afirmaciones son:

  • Las afirmaciones son destinado a para ser utilizado únicamente como un medio para detectar errores de programación, también conocidos como errores. Por el contrario, una excepción puede indicar otro tipo de error o condición “excepcional”; por ejemplo, entrada de usuario no válida, archivos perdidos, montón lleno, etc.
  • El lenguaje Java proporciona soporte sintáctico para aserciones, en forma de assert declaración. Compara lo siguiente:

    if (x != y) 
         throw new SomeException("x != y");
    
    
    assert x != y;
    
  • Lo que es más importante, Java le permite habilitar o deshabilitar la verificación de aserciones globalmente o en clases individuales cuando inicia la JVM.

Nota: algunas personas dicen que deberías siempre ejecute el código de producción con la verificación de aserciones desactivada. Tiendo a estar en desacuerdo con esto como una declaración general. Si se sabe que su código de producción es estable Y necesita exprimir ese último rendimiento, entonces desactivar las aserciones es bueno. Pero, si un (digamos) golpe de rendimiento del 10% no es un problema real, preferiría que una aplicación muera con un error de afirmación si la alternativa es continuar y corromper mi base de datos.

@Mario Ortegón comentó así:

El “apagado” se debe a que las aserciones se pueden usar para verificar el resultado de un algoritmo optimizado comparando su implementación con un algoritmo conocido, pero lento. Entonces, en desarrollo está bien invocar eso O(N^3) método para afirmar que el O(log N) algoritmo funciona según lo previsto. Pero esto es algo que no quieres en producción.

Ya sea que creas que es o no buena práctica para apagar aserciones en producción, definitivamente es mala práctica para escribir aserciones que tienen un impacto significativo en el rendimiento cuando están habilitadas. ¿Por qué? Porque significa que ya no tiene la opción de habilitar aserciones en producción (para rastrear un problema) o en sus pruebas de estrés/capacidad. En mi opinión, si necesita hacer O(N^3) pruebas previas y posteriores a la condición, debe hacerlo en sus pruebas unitarias.

La excepción es un mecanismo para verificar si la implementación se está ejecutando sin errores esperados o inesperados o no. Entonces, vemos que las excepciones se usan básicamente para manejar incluso las condiciones imprevistas durante la ejecución de una aplicación de una mejor manera y, por lo tanto, el uso efectivo de las excepciones da como resultado una aplicación robusta.

Las aserciones nunca deben ser parte de la implementación de alguna funcionalidad de la aplicación. Solo deben usarse para verificar las suposiciones, solo para estar seguros de que lo que asumimos al diseñar la solución también es válido en la práctica.

referencia: http://geekexplains.blogspot.com/2008/06/asserions-in-java-assertions-vs.html

Eres capaz de añadir valor a nuestro contenido contribuyendo tu veteranía en las reseñas.

¡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 *