2011-02-19 16 views

Respuesta

2

Las aserciones se pueden desactivar (de hecho, normalmente lo están), por lo que no son útiles para validar la entrada del usuario, por ejemplo.

29

Validate.is True y 'assert' sirven para fines completamente diferentes.

afirman
declaraciones de aserción de Java se utilizan normalmente para la documentación (por medio de afirmaciones ) bajo qué circunstancias métodos pueden ser invocadas, y lo que sus interlocutores pueden esperar para ser verdad después. Las aserciones pueden ser opcionalmente verificadas en tiempo de ejecución, lo que resulta en una excepción AssertionError si no son válidas.

En términos de diseño por contrato, las aserciones se pueden usar para definir las pre y postcondiciones , así como las invariantes de clase. Si en el tiempo de ejecución se detecta que no se mantienen, esto apunta a un problema de diseño 0 implementación en el sistema.

Validate.isTrue
org.apache.commons.lang.Validate es diferente. Ofrece un conjunto simple de métodos similares a JUnit que verifican una condición y lanzan una "excepción de objeto ilegal" si la condición no se cumple.

Normalmente se utiliza cuando una API pública debe tolerar la entrada incorrecta . En ese caso, su contrato puede prometer arrojar una IllegalArgumentException en una entrada errónea. Apache Validate ofrece una abreviatura conveniente para implementar esto.

Dado que se emite una IllegalArgumentException, no tiene sentido que use Apache's Validate para verificar las postcondiciones o invariantes. Del mismo modo, es incorrecto utilizar 'assert' para la validación de la entrada del usuario, , ya que la verificación de la afirmación puede desactivarse en tiempo de ejecución.

El uso de ambos
Es posible, sin embargo, utilizar ambos al mismo tiempo, aunque para diferentes propósitos. En este caso, el contrato debe explícitamente requerir que IllegalArgumentException se levante con ciertos tipos de entrada. Esto se implementa a través de Apache Validate. Los invariantes y las postcondiciones simplemente se afirman, así como como posibles precondiciones adicionales (por ejemplo, afectando el estado del objeto). Por ejemplo:

public int m(int n) { 
    // the class invariant should hold upon entry; 
    assert this.invariant() : "The invariant should hold."; 

    // a precondition in terms of design-by-contract 
    assert this.isInitialized() : "m can only be invoked after initialization."; 

    // Implement a tolerant contract ensuring reasonable response upon n <= 0: 
    // simply raise an illegal argument exception. 
    Validate.isTrue(n > 0, "n should be positive"); 

    // the actual computation. 
    int result = complexMathUnderTrickyCircumstances(n); 

    // the postcondition. 
    assert result > 0 : "m's result is always greater than 0."; 
    assert this.processingDone() : "processingDone state entered after m."; 
    assert this.invariant() : "Luckily the invariant still holds as well."; 

    return result; 
} 

Más información:

  • Bertrand Meyer, "Aplicación de Diseño por contrato", IEEE Computer, 1992 (pdf)
  • Johsua Bloch. Effective Java, 2nd ed., Item 38. Comprueba los parámetros de validez.(google books)
+1

Johsua Bloch. * Effective Java *, Item 23: Comprueba los parámetros de validez. – artdanil

1

@thilo es el adecuado para afirmar palabra clave, pero tenga en cuenta por la afirmación como la aserción de primavera.

Ver ConditionalFailuresExplained de guayaba.

  • Condición previa "en mal estado (el que llama)."
  • aserción "metí la pata."
  • Verificación "Alguien que dependo en mal estado."
Cuestiones relacionadas