Utilidad de System.Diagnostics.Contracts en la pregunta

Question

He estado jugando con la nueva clase System.Diagnostics.Contracts porque me pareció muy útil al principio. Métodos estáticos para verificar los argumentos entrantes, los valores devueltos, etc. Era una interfaz limpia y podía reemplazar muchas declaraciones if-then y herramientas de biblioteca creadas internamente.

Sin embargo, parece menos que útil en la mayoría de situaciones de tiempo de ejecución. Por lo que puedo decir, no arroja un error, así que no puedo detectar nada para saber si un contrato falló. Aparece un cuadro de diálogo con el error. Si estoy ejecutando un servicio wcf en una caja remota que rara vez tiene un aspecto humano ... ¿cómo podría saber si el contrato falló? Si no puedo atrapar el hecho de que ocurrió el error, ¿cómo podría informar a la persona que llama del servicio que se habían muerto?

Throw-Catch ha existido por un tiempo, no entiendo por qué los contratos quieren omitir esto. ¿Estoy tratando de usar esto incorrectamente? Si es así, entonces alguien me da una situación de la vida real donde un contrato de tiempo de ejecución tiene sentido. Ken

Answer 1

De lo que puedo decir, que no arroja un error así que no puedo coger cualquier cosa por saber si el contrato no.

Si usted necesita para lanzar una excepción en particular para llamar código de atrapar, entonces debería usar los métodos Contract.Requires<TException> o legado si-entonces-tiros seguido por Contract.EndContractBlock(). Haría esto cuando otro código ya espera y depende de las excepciones normales que se lanzan, por ejemplo.

Ver Sección 5.1: Argumento Validación y contratos del user manual para una explicación completa de cuándo utilizar las diferentes formas de condición previa.

Aparece un cuadro de diálogo con el error.

Si no marcas "Afirmar de Insuficiencia Contrato" en la pestaña "Code Contracts" de la configuración del proyecto, obtendrá una excepción real lanzado en el punto infractor en el código durante la depuración, en lugar de un cuadro de diálogo. Esto no es para atrapar, sin embargo.

saque de captura ha sido de alrededor de un rato, no entiendo por qué contratos quieren pasar por alto esto. ¿Estoy tratando de usar esto incorrectamente? Si es así, entonces alguien me da una situación de la vida real donde un contrato de tiempo de ejecución tiene sentido.

Sección 7.5: Racional de tiempo de ejecución Comportamiento y Sección 7.6: ContractException del user manual explicar por qué funciona de esta manera.

La idea es que nunca tenga que escribir programas que contengan una lógica específica que maneje las violaciones de contrato. Nunca deberían ocurrir en los programas correctos e indicar una falla grave en el código que debe corregirse. Esto es similar a cómo debe evitar atrapar ArgumentNullException.

Debería seguir generando excepciones normales en circunstancias excepcionales que no indiquen fallas en el código en sí, como cuando no se pudieron encontrar los archivos. Esto permite que el código de llamada maneje esa circunstancia según corresponda.

Si estoy ejecutando un servicio wcf en una caja remota que rara vez tiene un aspecto humano ... ¿cómo podría saber si el contrato falló?

Preferiblemente, debe probar el software tanto como pueda antes de usarlo, para asegurarse de que nunca viole ningún contrato.

Si tiene una necesidad específica de anular el comportamiento del tiempo de ejecución, puede hacerlo escribiendo su propia clase de tiempo de ejecución de contrato. Consulte Sección 7.7: Proporcionar una clase de tiempo de ejecución personalizada del contrato del user manual para obtener más información.

Editar: En respuesta al comentario más abajo ...

Usted dice que está destinado a encontrar defectos en el código, pero la mayoría de los fallos en el código viene de los datos transmitidos desde fuentes externas, no los códigos fallan Y el software necesita ambas cosas, registrar el hecho de que alguien transmitió datos incorrectos y decirles que pasaron datos incorrectos para que puedan solucionarlo.

Condiciones previas son contratos que definen cuándo un método es mascotas a ser llamado, y están destinados a ser verificada por la persona que llama en el momento de la llamada al método. El verificador de tiempo de ejecución inyectará las comprobaciones apropiadas en el código de llamada, no el método en sí. Si tiene el verificador estático disponible, se lo señalará cada vez que no asegure las condiciones previas antes de llamar a ese método.

En su situación, los métodos internos que procesan los datos deben definir condiciones previas que indiquen qué tipo de datos permiten. Cuando los datos se transfieren desde fuentes externas que no puede controlar, debe validarlo y manejarlo de la manera habitual; no quiere usar contratos de código para esto. Sin embargo, si, por ejemplo, olvida validar por completo esos datos, se encontrará con una violación del contrato cuando llame al código interno con las condiciones previas. Esto indica un error en su propio código.