c# - Lanzar una excepción vs Contrato.Requiere<T>?
exception error-handling (2)
Me pregunto si debo lanzar excepciones o llamar a Contract.Requires<TException>
Por ejemplo:
public static void Function(String str)
{
if (str == null) throw new ArgumentNullException("str", "Input string cannot be null.");
// ...
}
vs
public static void Function(String str)
{
Contract.Requires<ArgumentNullException>(str != null, "Input string cannot be null.");
// ...
}
Como Contract.Requires<TException> no requiere el símbolo CONTRACTS_FULL , también puedo mantenerlo en mis versiones de lanzamiento.
Esta es mi consideración:
Con: No puede llamar a una versión sobrecargada del constructor de tipo de excepción personalizado. Simplemente no hay forma de pasar parámetros adicionales al constructor.
Pro: soporte de herramientas estáticas (por ejemplo, informar a la persona que llama de la violación del contrato).
¿Cuál debo usar y para qué tipo de situación?
La compensación básica entre if-then-throw y Requires<TException> como se documenta en la guía del usuario de CodeContract es cómo se construye con los bits de su versión.
Caso 1 : solo utiliza if-then-throw , no Requires<TException> . En este caso, puede construir sus bits de lanzamiento sin ejecutar las herramientas de contrato en su dll / exe. La ventaja es que tiene compilaciones más rápidas y no hay riesgo de que la herramienta introduzca errores. Una segunda ventaja es que los miembros del equipo pueden optar por no usar las herramientas CodeContract. Las desventajas son que no obtiene la herencia del contrato de los requisitos, y sus contratos no son necesariamente visibles para las herramientas (a menos que use EndContract ). Puede especificar este caso utilizando el modo de ensamblaje: Validación de parámetros personalizados
Caso 2 : decide ejecutar las herramientas de CodeContract en sus bits de lanzamiento siempre. Esto le permite utilizar Requires<TException> y obtiene la herencia de los contratos, incluida la instrumentación de interfaces, etc. Sus contratos son limpios y las herramientas son reconocibles. La desventaja es que todos los que construyen su código deben tener instaladas las herramientas CodeContracts. Especifique este caso utilizando el modo de ensamblaje: Estándar en el panel de propiedades del contrato.
Espero que esto se aclare.
No estoy seguro de que haya diferencias entre los dos enfoques, pero aquí hay dos razones por las que prefiero los contratos ...
1) El código es mucho más limpio, ya que está escribiendo una declaración en la parte superior del método que muestra las suposiciones en las que se basa el método. No obstruye el código con la implementación de lo que sucede si se viola la suposición.
2) Obtiene la ventaja de que Visual Studio retoma los contratos de código cuando escribe el código y le da pistas sobre cuál es el método que está a punto de llamar. Esto le ayuda a asegurarse de que está enviando los parámetros válidos del método, sin tener que saltar a la definición del método para verificar el código allí.
Una vez que el código está compilado y en ejecución, no creo que haya diferencias significativas.
Espero que esto ayude.