Excepción Vs Aserción

Question

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

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

Answer 1

Utilice 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, esto debería ser explícito utilizando excepciones. (Se podría, sin embargo, opta por realizar la validación de argumentos en métodos privados usando afirmaciones, sobre la base de que una violación en ese punto se debe a un fallo interno en lugar de un error externo.)

Alternativamente Es toda razonable (IMO) para 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 aserciones, pero no es lo suficientemente claro para eliminar las preferencias por completo.)

Answer 2

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

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

Answer 3

excepción es un mecanismo de comprobar si la aplicació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 aserciones nunca deben ser parte de la implementación de algunas funcionalidades 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 4

aserciones Java se construyen en la parte superior de las excepciones de Java y el 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 principales diferencias entre las excepciones y las afirmaciones son:

• Las afirmaciones son destinados a servir únicamente como un medio para detectar errores de programación, también conocido como errores. Por el contrario, una excepción puede indicar otros tipos de error o condición "excepcional"; p.ej. entrada de usuario no válida, archivos perdidos, montón completo, etc.

• El lenguaje Java proporciona soporte sintáctico para aserciones, en forma de la declaración assert. Compare los siguientes:

  if (x != y) { 
      throw new SomeException("x != y"); 
  } 
  
  assert x != y; 
  

• que es más importante, Java le permite activar o desactivar la afirmación de la comprobación a nivel mundial o en clases individuales cuando se inicia la JVM.

Nota: algunas personas dicen que usted debe siempre el código de producción plazo con la afirmación comprobación desactivado.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 "apagar" es porque afirmaciones pueden ser utilizados para verificar el resultado de un algoritmo optimizado mediante la comparación de su aplicación contra un conocido, pero lento, algoritmo. Entonces, en desarrollo, está bien invocar ese método O(N^3) para afirmar que el algoritmo O(log N) funciona según lo previsto. Pero esto es algo que no quieres en producción.

Independientemente de si usted piensa que es una buena práctica para apagar las afirmaciones de la producción, es definitivamente una mala práctica escribir afirmaciones que tienen un impacto significativo en el rendimiento cuando está activado. ¿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 hacer O(N^3) pruebas previas o posteriores a la condición, debe hacerlo en las pruebas de su unidad.

Answer 5

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 

yo personalmente creo que afirman debe única ser utilizada cuando se sabe que algo está fuera deseables límites, pero puede 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.

El principal inconveniente para mí es si desea derribar un sistema en vivo/producción con una excepción para evitar corrupción y facilitar la resolución de problemas, o si ha encontrado una situación que nunca debe continuar desapercibida en prueba/depurar versiones, pero se podría permitir que continúen en producción (registrando una advertencia, por supuesto).

cf. http://c2.com/cgi/wiki?FailFast véase también mi C# copia de esta respuesta: Debug.Assert vs. Specific Thrown Exceptions

Answer 6

aserción se utiliza para la depuración de los supuestos que se requieren para ser controladas en tiempo de ejecución solamente activando la función de aserción mientras excepción es para comprobar las condiciones específicas que deben comprobarse durante la ejecución de la programa para evitar que el programa termine.

Answer 7

Las aserciones 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 de ejecución alternativa, 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 pone una afirmación en el lugar crítico y las invariantes dejan de ser válidas, su 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.