2009-04-24 9 views
7

¿Cuál es el punto de poner afirmaciones en nuestro código? ¿Cuáles son los beneficios de la programación asertiva?Beneficios de la Programación Asertiva

private void WriteMessage(string message) 
{ 
    Debug.Assert(message != null, "message is null"); 

    File.WriteAllText(FILE_PATH, message); 
} 

Por ejemplo, podemos verificar la variable del mensaje y arrojar una excepción aquí. ¿Por qué uso assert aquí? ¿O es este un ejemplo equivocado para ver los beneficios de las afirmaciones?

Respuesta

9

También apoyan la filosofía de fallar rápido, explican en this article por Jim Shore.

1

Si hay una condición previa especificada para que el método tome un parámetro de mensaje no nulo, entonces desea que el programa falle tan pronto como la condición previa no se mantenga y el origen del error debe entonces ser arreglado

creo afirmaciones son más importantes en el desarrollo de software crítico. Y ciertamente preferiría usar aserciones cuando el software ha sido formalmente especificado.

+0

Comenté esto porque sigue los principios de diseño del libro "Diseño por contrato". Donde especifica sus funciones pre y post condición. Aunque las condiciones de publicación normalmente tienden a ser más complejas, pre condicionan según el contexto. Solo para una mini respuesta. Las afirmaciones son útiles para captar la comunicación del desarrollador o de la falla entre los equipos sobre cómo funcionan dichos módulos. También debe haber una separación entre el armazón central del motor y también el área de entrada del usuario para mezclar dos juntas es una locura. – Chad

1

Para una excelente discusión de las afirmaciones (y muchos otros temas relacionados con la construcción de código), echa un vistazo a Code Complete por Steve McConnell. Dedica un capítulo entero al uso efectivo de las afirmaciones.

1

Los uso para verificar que se me ha proporcionado una clase dependiente válida. por ejemplo, en el constructor DI, generalmente está aceptando algún tipo de clase externa de la que dependa para proporcionar alguna acción o servicio.

por lo que puede valer (classRef - null, "classRef no puede ser nulo"!); en lugar de esperar que pases un mensaje a classRef y obtener alguna otra excepción como excepción: violación de acceso o algo igualmente ambiguo que podría no obviorse inmediatamente al mirar el código.

2

Una distinción importante a considerar es qué tipo de errores que le gustaría coger con las afirmaciones. A menudo uso aserciones para detectar errores de programación (es decir, llamar a un método con un parámetro nulo) y un mecanismo diferente para manejar los errores de validación (por ejemplo, pasar un número de seguridad social de la longitud incorrecta). Para el error de programación capturado con la aserción, quiero fallar rápido. Para el error de validación, quiero responder de manera menos drástica porque puede ser normal que haya errores en los datos (por ejemplo, un usuario que ingresa datos de algún tipo). En esos casos, el manejo adecuado podría ser informar el error al usuario y continuar funcionando.

7

Cuando algunas personas escribirían:

/* 
* This can never happen 
*/ 

Es mucho más práctico para escribir:

assert(i != -1); 

me gusta usar afirma, ya que son fácilmente apagados con un simple tiempo de compilación constante, o de hecho para hacer otra cosa como preparar un informe de error. Normalmente no dejo las afirmaciones activadas (al menos, no de la manera habitual) al liberar algo.

El uso de ellos me ha salvado de cometer errores muy estúpidos en los ordenadores de otras personas .. esas almas valientes que disfrutan de probar mi código alfa. Usarlos más herramientas como valgrind ayuda a garantizar que capture algo horrible antes de comprometerlo.

0

Es muy útil para probar nuestras suposiciones. Las afirmaciones constantemente aseguran que lo invariante sea verdadero.En resumen, se utiliza para los siguientes propósitos,

  • Permite implementar sistema a prueba de rápido.
  • Es reduce la propagación de error debido a los efectos secundarios.
  • Prohíbe (tipo de comprobación de la cordura) que el sistema entre en un estado incoherente debido a datos de usuario o por cambios de código posteriores.

A veces, estoy a favor del uso de assert_return() cuando no queremos usar try/catch/throw.

private void WriteMessage(string message) 
{ 
    assert_return(message != null, "message is null"); // return when false 
    File.WriteAllText(FILE_PATH, message); 
} 

Sugiero assert_return() para detener la aplicación al informar un error en la compilación de prueba. Y luego, en el sistema de producción, debe registrar y error, y regresar de la función diciendo que no puede hacer eso.

Cuestiones relacionadas