library - java assert keyword

Excepción Vs Afirmación

Question

¿Cuál es la diferencia entre el manejo de excepciones de Java y el uso de condiciones de assert ?

Se sabe que Assert es de dos tipos. Pero, ¿cuándo deberíamos usar assert keyword?

Answer 1

Assert es solo para fines de depuración y su condición desencadenante no debería ocurrir (puntero nulo cuando no debería haber, etc.)

La excepción es para eventos especiales del sistema que siempre pueden ocurrir: FileNotFound, ConnectionToServerLost, etc.

Answer 2

Ejemplo de un buen uso de Assert:

assert flibbles.count() < 1000000; // too many flibbles indicate something is awry
log.warning("flibble count reached " + flibbles.count()); // log in production as early warning

Personalmente, creo que Assert solo debe usarse cuando sabes que algo está fuera de los límites deseables , pero puedes estar seguro de que es razonablemente seguro continuar. En todas las demás circunstancias (no dude en señalar las circunstancias en las que no he pensado) use excepciones para fallar de manera rápida y difícil.

La clave para mí es si quieres derribar un sistema en vivo / producción con una excepción para evitar corrupción y facilitar la solución de problemas, o si has encontrado una situación que nunca debería permitirse continuar desapercibida en las versiones de prueba / depuración, pero podría se le permitirá continuar en producción (registrando una advertencia por supuesto).

cf. http://c2.com/cgi/wiki?FailFast vea también mi copia c # de esta respuesta: Debug.Assert vs. Excepciones específicas arrojadas

Answer 3

La aserción se usa para la depuración de las suposiciones requeridas que se verificarán en el tiempo de ejecución solo habilitando la característica de afirmación, mientras que la excepción es verificar las condiciones específicas que se verificarán durante la ejecución del programa para evitar que el programa finalice.

Answer 4

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 de excepciones resulta eficazmente en una aplicación sólida.

Las afirmaciones nunca deberían ser parte de la implementación de alguna funcionalidad de la aplicación. Solo deberían 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

Answer 5

Las afirmaciones son muy similares a las excepciones, de hecho, al igual que las excepciones, marcarán un problema, pero a diferencia de las excepciones, no sugerirán ninguna ruta alternativa de ejecución, sino que simplemente fallarán. ¿Por qué usar aserciones, si puede hacer lo mismo, y más con excepciones?

Úselos cuando los problemas no se reparen, y en realidad NUNCA DEBERÍAN SUCEDER EN PRIMER LUGAR. Esto suena raro al principio: ¿no queremos proteger nuestro código de TODOS los posibles problemas? Por lo general, sí. Pero hay un caso en que no lo hacemos. Este caso se llama: "Diseño por contrato".

Supongamos que está escribiendo una solicitud para un banco. Como desarrollador, no es posible que soporte todas las condiciones financieras posibles. Entonces, antes de comenzar a codificar, obtiene una especificación del banco que le proporciona los rangos válidos que esta aplicación debe admitir. Entonces, su aplicación está diseñada por contrato (según las especificaciones del banco). Este contrato definirá los principios fundamentales que siempre deberían ser ciertos para que su aplicación funcione. Estos principios fundamentales se llaman "invariantes" (porque no pueden cambiar). El diseño por contrato simplifica su vida como desarrollador: usted solo es responsable de respaldar el alcance del trabajo definido en el contrato.
Es importante verificar los valores de estas invariantes en su código, pero no debe verificarlos como si fueran excepciones y tratar de evitarlos. Si están equivocados, debe fallar porque las entradas no han cumplido sus obligaciones contractuales.

Lo interesante es que si no colocas una afirmación en el lugar crítico y las invariantes se vuelven inválidas, tu código fallará de todos modos. Simplemente no sabrás por qué. Entonces, para resumir, las afirmaciones se usan para verificar las invariantes. Van de la mano del principio "diseño por contrato". Úselos para solucionar un problema, por eso se desactivan en producción.

Otro caso de uso: si confía en una biblioteca externa en la que no confía plenamente, es posible que desee usar declaraciones de afirmación al llamarla.

Algunos también usan aserciones como un sustituto rápido y sucio de una excepción (ya que es muy fácil de hacer), pero conceptualmente eso no es lo correcto.

Answer 6

Las aserciones de Java se crean sobre excepciones de Java y manejo de excepciones. De hecho, cuando una afirmación de Java falla, el resultado es una excepción AssertionError que se puede capturar como cualquier otra excepción de Java. Las diferencias clave entre excepciones y aserciones son:

• Las afirmaciones están destinadas a ser utilizadas únicamente como un medio para detectar errores de programación, también conocidos como errores. Por el contrario, una excepción puede indicar otros tipos de error o condición "excepcional"; por ejemplo, entrada de usuario no válida, archivos perdidos, montón completo, etc.

• El lenguaje Java proporciona soporte sintáctico para aserciones, en forma de declaración de afirmación. Compare 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 afirmaciones globalmente o en clases individuales cuando inicia la JVM.

Nota: algunas personas dicen que siempre debe ejecutar el código de producción con la verificación de afirmación 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 el último rendimiento, entonces desactivar las afirmaciones es bueno. Pero, si un (digamos) rendimiento del 10% no es un problema real, preferiría que una aplicación muera con un error de aserción si la alternativa es continuar y dañar mi base de datos.

@ Mario Ortegón comentó así:

El "apagado" se debe a que las afirmaciones se pueden usar para verificar el resultado de un algoritmo optimizado al comparar su implementación con un algoritmo bien conocido pero lento. Entonces, en desarrollo, está bien invocar ese método O(N^3) para afirmar que el algoritmo O(log N) funciona como se esperaba. Pero esto es algo que no quieres en producción.

Independientemente de si considera o no que es una buena práctica desactivar afirmaciones en la producción, definitivamente es una mala práctica escribir afirmaciones que tengan un impacto significativo en el rendimiento cuando estén habilitadas. ¿Por qué? Porque significa que ya no tiene la opción de habilitar las aserciones en producción (para rastrear un problema) o en su prueba de estrés / capacidad. En mi opinión, si necesita realizar O(N^3) pruebas previas / posteriores a la condición, debe hacerlo en las pruebas de su unidad.

Answer 7

Use las aserciones para las verificaciones lógicas internas dentro de su código, y las excepciones normales para las condiciones de error fuera del control de su código inmediato.

No olvide que las afirmaciones pueden activarse y desactivarse: si le importan cosas como la validación de argumentos, eso debe ser explícito utilizando excepciones. (Sin embargo, podría optar por realizar la validación de argumentos en métodos privados utilizando aserciones, basándose en que una violación en ese punto se debe a un error interno en lugar de a un error externo).

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