Para tirar o no tirar

Question

// 
// To Throw 
void PrintType(object obj) 
{ 
    if(obj == null) 
    { 
     throw new ArgumentNullException("obj") 
    } 
    Console.WriteLine(obj.GetType().Name);  
} 

// 
// Not to Throw 
void PrintType(object obj) 
{ 
    if(obj != null) 
    { 
     Console.WriteLine(obj.GetType().Name); 
    } 
} 

¿Qué principio mantener?

personalmente prefiero la primera uno su ejemplo amistoso con el desarrollador (notificado sobre cada una "anomalía"). El segundo es decir fácil de usar (deje que el usuario continúe trabajando incluso si "dentro" no todo funciona bien).

Creo que es más complicado encontrar errores y errores en la fase de mantenimiento cuando silenciosamente dejas que las cosas continúen. Si algo sale mal, no se le notificará de inmediato, y algunas veces tendrá errores muy alejados de la causa principal del error, y se perderá mucho tiempo para encontrarlo.

¿Qué opinas?

Answer 1

Si el cuerpo del método maneja el obj nulo correctamente (en otras palabras, obj! = Null no es un requisito), entonces no hay necesidad de lanzar una excepción.

En todos los demás casos: Tiro. Deje que el cliente asuma la responsabilidad de su entrada defectuosa.

Answer 2

El segundo es letal. Fallar silenciosamente es siempre lo que no debe hacer. Supongamos que este fuera el sistema bancario en el banco que posee su cuenta. ¿Te gustaría si hubiera un problema para pagar tu salario y el sistema lo ignoró silenciosamente?

Answer 3

Considerar el uso de Null Object pattern es muy útil para no saturar el código con try-catch, comprobaciones nulas (o dios no permita que se cometan errores).

Answer 4

Throw.

Deje que el llamante de una función determine si es lo suficientemente importante como para lanzar una excepción al usuario en un valor nulo, pero la función en sí debería arrojarse debido al argumento no válido.

Answer 5

En este ejemplo particular, no dar nada a una impresora es como decir "imprimir nada", por lo que funciona como debería.

Sé que esto es un ejemplo, pero es solo para aclarar que esto es relativo.

Si su código muestra mensajes fáciles de usar sobre excepciones de alguna manera, ¿qué diferencia hace? el primero sería tanto desarrollador como amigable para el usuario.

Answer 6

Yo diría que depende de su preferencia (desarrollador). Desde la perspectiva del usuario, nunca debería ver una excepción no controlada, pero eso no significa que no pueda usar excepciones.

Prefiero la primera, porque creo que null es una construcción totalmente innecesaria (y molesta), así que me esfuerzo por codificar sin ella. Si hay un null en algún lugar, alguien cometió un error, por lo que lo mejor es simplemente irse a pique en lugar de pretender que todo está bien.

Al final depende de lo que usted considera que es la semántica del método. Si se supone que el método acepta nulos, entonces debe elegir la opción número dos. Si se supone que el método solo acepta argumentos reales (que prefiero), entonces debe elegir la opción número uno.

Answer 7

Realmente depende de cuáles son sus invariantes. Si el parámetro es optiona, ignorar un parámetro null es correcto, pero si el parámetro es obligatorio, eso ocultará un error en su aplicación. Además, y dependiendo del idioma, si el invariante es suficientemente malo, puede considerar una tercera opción: abortar la aplicación.

Todas las discusiones sobre si se debe utilizar o no excepciones siempre se pueden asignar a la decisión sobre si la situación es excepcional o no, y si es excepcional, tirar o más bien abortar la aplicación depende de si es recuperable o no.

Answer 8

Siempre Throw, excepto en código de depuración/diagnóstico. Es muy embarazoso tener una NullPointerException que se produce en el código de producción en un punto donde solo se debe generar un mensaje de depuración, p.

log.debug("id of object is " + obj.getId()) 

donde el registrador está desactivado y obj es nulo.

Answer 9

Es muy subjetivo, pero siempre prefiero ignorar los errores no fatales o recuperables. Póngalos en registros, si es necesario, pero si sabe cómo continuar, hágalo.

Tenga en cuenta que cuando digo fatal, en realidad depende de la función en sí. Diga, hay una función API que obtiene ID y un puñado de otros parámetros. Supongamos que esta ID también puede adivinarse a partir de esas otras cosas que se transmiten. La función de la API debería adivinar si puede, pero la función en algún lugar que hace todo el trabajo debería obtener una identificación no nula y arrojar de lo contrario. Porque la función API de alto nivel no es fatal, sabe cómo adivinarla, pero para la función de bajo nivel es fatal, se supone que debe hacer algo con esa ID y con valor nulo no puede continuar.

Todos los errores fatales deben tenerse en cuenta, por supuesto.

Answer 10

Lanzar una excepción (si nulo es un error) parece mucho mejor que ignorar silenciosamente un error.

hay una tercera opción que puede considerar:

void PrintType(object obj) 
{ 
    Console.WriteLine(obj.GetType().Name); 
} 

Esto también se produce una excepción cuando obj es nula. La ventaja de esto es que implica menos código. La desventaja de este enfoque es que es más difícil determinar si obj puede ser nulo.

Answer 11

identificación va a

vacío TipoImpresión (objeto obj) { Console.WriteLine (obj.GetType() Nombre.); }

Answer 12

tercera opción, la mitad en pseudocódigo:

// To Throw A Clean Error 
void PrintType(object obj) 
{ 
    if(obj == null) 
    { 
     throw new ArgumentNullException(STANDARD_ERROR_MESSAGE, obj) 
    } 

    Console.WriteLine(obj.GetType().Name);  
} 

puede recogerla todos errores y se envuelven en un solo lugar, por lo que el usuario ve texto estándar:

Ha habido un error. Si persiste este error , póngase en contacto con un administrador .

O agregue algunos errores, todos ellos fáciles de usar, y los mostrará directamente al usuario. "Ha occurido un error de conexión." "Ha ocurrido un error de autenticación". "Ha ocurrido un error del sistema". Y así.

En el back-end, tienen todos los errores y se ha registrado su seguimiento de pila, por lo que puede utilizar la información de depuración de esa manera.

Answer 13

Realmente depende de lo que la función está definida para hacer. El aspecto más importante es tener un comportamiento claramente definido y que la función lo implemente correctamente.

Ahora, si la pregunta es si es mejor definir la función para aceptar nulo e imprimirla, o para no aceptarla y lanzar una excepción, diría que la última, porque probablemente sea menos propensa a errores para el usuario para comprobar nulo antes de llamar a la función, si eso es una posibilidad.

Answer 14

Si api si está expuesto afuera, siempre haga una comprobación de argumentos y arroje una excepción basada en argumentos para que el usuario de la API pueda obtener el resultado.