Creación de una clase de afirmación personalizada

Question

Estoy siguiendo el Fallar rapido principal. Me pregunto si es una buena práctica tener una clase de afirmación para verificar mis argumentos de parámetros del constructor.

Por ejemplo:

public static class Assertions
{
    public static void ParamterIsNotNull(object subject, string paramName = "")
    {
        if (subject == null) throw new ArgumentNullException(paramName, "Paramter cannot be null");
    }
}

y en uso:

public class Test
{
    public Test(object obj)
    {
        Assertions.ParamterIsNotNull(obj, "obj");
    }
}

¿Es esta buena práctica descargar la excepción que arroja a otra clase, o es mejor lanzar la excepción directamente en el constructor?

Answer 1

Por lo que he leído (al final del artículo) Martin dice que es bueno hacer ambas cosas, falla rápida, proporcionando la excepción significativa y "fallas lentas", dando al usuario la alivio de decir que el soporte de contacto y continuar con Las tareas que se pueden completar con éxito sin importar la excepción.

El ejemplo del sistema por lotes fue muy agradable en este caso: aunque 1 elemento del lote puede estar a la altura, el usuario probablemente querrá que el resto sea dalth. Handler decide continuar con el siguiente elemento y agregar el error para que pueda mostrarlo al usuario y enviar notificación al equipo de desarrollo).

De esta manera, ambos se completan: la mayoría del trabajo de los usuarios se realiza y el principio de falla rápida también se dispara.

Por lo tanto, depende de su caso concreto: tal vez si su clase participa en otras operaciones, habrá más clase global (o una clase de llamadas que lo use) que podrá decidir mejor si puede continuar o no.

Por otro lado, su clase no debería poder saber si la clase de llamadas puede hacer algún otro trabajo en caso de falla, por lo que debe lanzar su excepción en el constructor, sí. Esto es lo que pienso, sí :). Entonces, si su clase representa un elemento del lote, la persona que llama probablemente captará la excepción y continuará. Si se trata de algún tipo de clase de punto de entrada, entonces probablemente desee manejar con gracia la excepción (o no lanzarla en absoluto), muestre al usuario un mensaje de error y proporcione detalles (registro) para que el equipo de Dev pueda decir fácilmente donde estaba el problema.