¿La mejor manera de afirmar la condición previa y la condición posterior de los argumentos y valores en .NET?

Question

Últimamente he estado pensando en el diseño por contrato y me preguntaba qué piensa la gente sobre la mejor forma de afirmar la condición previa y la condición posterior de los valores en .NET. es decir, validar los valores de argumento de un método.

Algunas personas recomiendan Debug.Assert mientras que otras hablan sobre el uso de una sentencia if y una excepción. ¿Cuáles son los pros y los contras de cada uno?

¿Qué marcos están disponibles que recomiendas?

Answer 1

Eventualmente usaremos Contratos de Código cuando se envíe .NET 4.0. Sin embargo, en nuestro código de producción en este momento hemos tenido un gran éxito con una "Guardia" clase junto con una forma común de generar excepciones.

Para obtener más detalles, consulte mi publicación sobre esto .

Answer 2

Otra opción es Spec # .

Spec # es una extensión del lenguaje orientado a objetos C #. Extiende el sistema de tipos para incluir tipos no nulos y excepciones comprobadas. Proporciona contratos de método en forma de condiciones previas y posteriores, así como invariantes de objetos.

Answer 3

Prefiero las excepciones a las afirmaciones porque si se supone que es así y no lo es, quiero saberlo para poder solucionarlo, y la cobertura que recibimos en el modo de depuración no se compara con el uso o la cobertura de la vida real. , así que solo usar Debug.Assert no hace lo suficiente.

El uso de aserciones significa que no agregará demasiada información a su código de lanzamiento, pero significa que solo podrá ver cuándo y por qué se rompen estos contratos si los detecta en una compilación de depuración.

El uso de excepciones significa que puedes ver que el contrato se rompe cada vez que ocurre, depura o lanza, pero también significa que la versión de la versión contiene más controles y código.

Podría ir con un enfoque intermedio y usar Rastreo para rastrear sus condiciones previas y posteriores a algún tipo de registro de aplicación, que podría usar para depurar problemas. Sin embargo, necesitaría una forma de recopilar estos registros para conocer los problemas que enfrentan sus usuarios. También existe la posibilidad de combinar esto con excepciones para obtener excepciones para los problemas más graves.

La forma en que lo veo, sin embargo, es que si vale la pena hacer cumplir el contrato, entonces vale la pena lanzar una excepción cuando se rompa. Sin embargo, creo que eso se debe a una opinión y una aplicación de destino. Si lanza excepciones, es probable que desee alguna forma de sistema de informes de incidentes que proporcione informes de fallos cuando las excepciones generadas no se manejen.

Answer 4

Puede consultar el marco fluido en http://conditions.codeplex.com/ Su código abierto y gratuito.

Answer 5

Spec # es la forma de hacerlo, que es un superconjunto de C #. Ahora tiene " Contratos de código " ;, que es el idioma versión independiente de Spec #, por lo que ahora puede tener contratos de código en VB.NET, por ejemplo.