¿Cuál es la forma correcta de verificar la excepción de nulo?

Question

¿Cuál es el código más correcto?

if (HttpContext.Current.Response.Cookies[authCookieName] != null) { 
    HttpContext.Current.Response.Cookies[authCookieName].Value = "New Value"; 
} 

o

if (HttpContext.Current != null) 
    if (HttpContext.Current.Response != null) 
     if (HttpContext.Current.Response.Cookies != null) 
      if (HttpContext.Current.Response.Cookies[authCookieName] != null) 
       HttpContext.Current.Response.Cookies[authCookieName].Value = "New Value"; 

Answer 1

Si cualquiera de HttpContext, HttpContext.Current, HttpContext.Current.Response o Http.Current.Response.Cookies es nulo, ya se encuentra en problemas. Deja que ocurra la excepción y arregla tu servidor web.

Answer 2

Ninguno es realmente más correcto, aunque evitaría el segundo, ya que los condicionales profundamente anidados tienden a ser difíciles de entender y mantener.

Si prefiere obtener una excepción de puntero nulo, use la primera. Si desea tratar nulos de otra manera o en silencio, use el segundo (o una versión modificada del segundo).

Answer 3

Si cree que hay una posibilidad de que Current, Response, Cookies o Cookies[authCookieName] podría ser null, y usted tiene una cosa razonable hacer si alguno de ellos es, entonces éste es el camino a seguir. Si las posibilidades son bajas, y/o no hay nada que pueda hacer si los intermedios son nulos, elija el primero, ya que es más conciso: lo mejor que puede hacer es obtener un mejor registro si usa el ejemplo ampliado.

Answer 4

podría intentar:

if(HttpContext.Current != null && 
    HttpContext.Current.Response != null && 
    HttpContext.Current.Response.Cookies != null && 
    HttpContext.Current.Response.Cookies[authCookieName] != null) 
{ 
    // do your thing 
} 

Answer 5

HttpContext.Current.Response.Cookies nunca será nula. Lo único que puede causar un nulo es si la cookie que está esperando no existe, entonces la primera es correcta. HttpContext.Current sería nulo si no aceptara una solicitud web :)

Answer 6

Ambos son buenos. Suponiendo que ya ha verificado todo lo demás que debe verificarse primero. Ej .:

private bool CheckSuspendersAndBelt() 
{ 
    try 
    { 
     //ensure that true is true... 
     if (true == true) 
     { 
      //...and that false is false... 
      if (false == false) 
      { 
       //...and that true and false are not equal... 
       if (false != true) 
       { 
        //don't proceed if we don't have at least one processor 
        if (System.Environment.ProcessorCount > 0) 
        { 
         //and if there is no system directory then something is wrong 
         if (System.Environment.SystemDirectory != null) 
         { 
          //hopefully the code is running under some version of the CLR... 
          if (System.Environment.Version != null) 
          { 
           //we don't want to proceed if we're not in a process... 
           if (System.Diagnostics.Process.GetCurrentProcess() != null) 
           { 
            //and code running without a thread would not be good... 
            if (System.Threading.Thread.CurrentThread != null) 
            { 
             //finally, make sure instantiating an object really results in an object... 
             if (typeof(System.Object) == (new System.Object()).GetType()) 
             { 
              //good to go 
              return true; 
             } 
            } 
           } 
          } 
         } 
        } 
       } 
      } 
     } 
     return false; 
    } 
    catch 
    { 
     return false; 
    } 
} 

(lo siento, no pudo resistir ... :))

Answer 7

El primer ejemplo que dio es más que suficiente. Como se mencionó, si alguno de los otros objetos es nulo, hay un problema con ASP.NET.

if (HttpContext.Current.Response.Cookies[authCookieName] != null) { 
    HttpContext.Current.Response.Cookies[authCookieName].Value = "New Value"; 
} 

Pero en vez de ensuciar el código con estos menudo muchos controles, se debe crear algunas funciones genéricas como SetCookie, GetCookie, getQueryString, y GetForm, etc., que acepte el nombre y valor (para establecer funciones) como parámetros, manejar la comprobación nula, y devuelve el valor o una cadena vacía (para obtener funciones). Esto hará que su código sea mucho más fácil de mantener y posiblemente mejorar, y si decide usar algo que no sean Cookies para almacenar/recuperar opciones en el futuro, solo tendrá que cambiar las funciones.