Manejar o no manejar parámetros nulos con excepciones

Question

Recuerdo haber leído alguna guía de manejo de excepciones que indicaba que no se recomienda verificar parámetros nulos. La justificación para esto era que, si dejaba el código como está, se generaría una excepción (NullReferenceExcpetion) cuando intentaba usar el parámetro. La alternativa es comprobar explícitamente null y lanzar una ArgumentNullException.

Esto le da el mismo efecto pero tiene líneas adicionales de código. Nunca escribirías código para manejar ninguna de las dos excepciones y, por lo tanto, podrías encontrarlas en tiempo de ejecución al probarlas y luego arreglar el código para evitar que las excepciones ocurran en primer lugar.

No estoy diciendo que estoy de acuerdo con la orientación pero sí tenía sentido cuando la leí por primera vez y todavía tiene sentido.

En general, solo compruebo los parámetros nulos en métodos no privados pero dejo métodos privados para arrojar una NullReferenceException.

¿Alguien sabe si hay alguna práctica de orientación definitiva/de facto en esto para que pueda actualizar mi enfoque si es necesario?

Answer 1

Esto da el mismo efecto pero estás líneas adicionales de código correctas

No, no lo hace. Considere lo siguiente:

public void TransferMoney(Account from, Account to, decimal amount) 
{ 
    from.Debit(amount); 
    to.Credit(amount); 
} 

vs

public void TransferMoney(Account from, Account to, decimal amount) 
{ 
    // Ideally do them separately 
    if (from == null || to == null) 
    { 
     throw new ArgumentNullException(); 
    } 

    from.Debit(amount); 
    to.Credit(amount); 
} 

Tanto fallará con excepciones - pero el primero fallará haber causado un primer efecto secundario. Eso es malo, y debe evitarse siempre que sea posible.

(Obviamente, en un escenario real Se supone que esto sería transaccional, y no habría ningún daño real hecho, pero lo lleve mi punto.)

Además, si un parámetro se utiliza como argumento para otro método - o peor aún, almacenado para su uso posterior - puede terminar con la excepción lanzada desde un completamente lugar diferente, de una manera que puede hacer completamente no es obvio cuál fue el problema original.

En general, solo compruebo los parámetros nulos en métodos no privados pero dejo métodos privados para arrojar una NullReferenceException.

Parece una política bastante razonable. Si se llama a un método privado/interno de algún código raro y me preocupa que pueda haberlo arruinado, a veces lo valido incluso en ese momento.

Answer 2

Con una marca de verificación, puede pasar el nombre del parámetro en la excepción, lo que simplifica la depuración.

if (x == null) throw new ArgumentNullException(nameof(x));