Pregunta

Suena como una pregunta estúpida con una respuesta obvia:)

Aún así me he aventurado a pedir simplemente estar doblemente seguro.

De hecho, estamos utilizando afirman como se indica a continuación

ArrayList alProperties = new ArrayList();

assert alProperties != null : "alProperties is null";

El problema es que hacer un documento pequeño y fácil de seguir, sobre afirma es difícil. Hay muchos libros sobre afirma, pero lo ideal es que les gusta dar un nuevo programador pautas muy sencillas de usar algo como afirma. Por cierto, hace un poco de herramienta como el cheque PMD para el uso apropiado de afirma?

Gracias de antemano.

¿Fue útil?

Solución

No hay ninguna razón sensata para usar afirma así. Si no se ha creado el objeto, por alguna razón, ni siquiera se llegó a su aserción (porque ha generado una excepción o la máquina virtual salió, por ejemplo)

Otros consejos

Hay algunas directrices bastante concisos sobre el uso de las afirmaciones de Sun en Programación con las afirmaciones . Ese artículo informa que asevera debe ser usado para cosas como invariantes interna, control de flujo de invariantes, y las condiciones previas, Condiciones posteriores, y Clase invariantes.

No, usted no desea comprobar la creación de objetos.

Si la creación del objeto falla, la JVM lanzar un OutOfMemoryError, y si esto sucede es muy probable que se screwd allá de la reparación de todos modos.

eso es como no confiar en la JVM. En cuanto a lo que se toma como un hecho, tienes que dibujar una línea en alguna parte ...

Esta aserción sólo estorba su código, que sería equivalente a esta aserción:

boolean a = true;
assert a : "A should be true"

Usted no debe estar probando la JVM, a menos que ese es el punto de su programa (por ejemplo, que es un banco de pruebas para una JVM que está haciendo). En su lugar debe estar probando sus precondiciones, post-condiciones e invariantes. A veces, estas pruebas son muy básico o muy caro.

Las condiciones previas, probablemente, sólo deben aparecer en el inicio de un método (si su tienen métodos muy largos, entonces usted debe romper ese método en partes más pequeñas, incluso si son todos privados).

Post-condiciones deberían dejar en claro lo que usted ha regresado a la persona que llama, no se prueba que la función sqrt acaba de regresar de la raíz cuadrada, pero es posible probar que era positivo para que quede claro lo que se esperaba (quizás código más tarde utiliza números complejos y los suyos no se ha probado para eso). En su lugar dejar un comentario en la parte inferior.

invariantes también a menudo no puede ser probada, no se puede probar que la solución actual es la correcta solución parcial (véase más abajo) - aunque esto es una de las cosas buenas de escribir cosas con la cola-recursividad. En su lugar, se declara el invariante con un comentario.

Si está llamando a las cosas por fuera, que sería también utilizar una aserción, por ejemplo, en el ejemplo, si tiene ArrayList.Create(), entonces es posible elegir la comprobación de aserción de null. Pero sólo porque no confía en el otro código. Si usted escribió ese código, se puede poner la afirmación (comentario o de otro tipo) en el método de fábrica en sí.

int max(int[] a, int n) {
  assert n <= a.length : "N should not exceed the bounds of the array"
  assert n > 0 : "N should be at least one"

  // invariant: m is the maximum of a[0..i]
  int m = a[0];
  for( int i = 1; i < n; n++ ) {
    if( m < a[i] )
      m = a[i];
  }

  // if these were not basic types, we might assert that we found
  // something sensible here, such as m != null
  return m;
}

En Java cada llamada a nuevos devuelve o una referencia no nula a los nuevos objetos o genera una excepción o un error. En el primer caso, su aserción es verdadera, en el segundo caso no se alcanzará la aserción, porque se termina en el próximo juego del bloque catch.

Este pruebas de aserción si su aplicación Java se rompe y en este caso ni siquiera se puede confiar en la aserción. Por lo que no haría tales afirma. Utilice valer para la restricción de objetos, que no son impuestas por el lenguaje (por ejemplo, si el método se pasa un parámetro que es nulo, pero no debería ser).

No estoy seguro de entender completa su pregunta, pero creo que las afirmaciones de este tipo no son NECESARIO.

Cuando se crea una instancia, si el flujo del programa continúe, la instancia no es una referencia nula.

¿Quieres ASSERTS para comprobar las propiedades invariantes o de su programa. Un buen documento para enseñar esto debe animar a los programadores a pensar en esas propiedades de una manera sistemática / metódica.

si falla la aserción, créeme, vas a tener problemas más grandes que sólo se ocupan de la aserción.

Si esa aserción falla creo que es hora de buscar otro trabajo porque el equipo no se comporta de la forma en que se supone que y cuando eso sucede todo el infierno va a desatarse!

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top