Me gustaría evitar el procesamiento posterior en un objeto si es null.

En el código siguiente se puedo comprobar si el objeto es nulo por cualquiera de las:

if (!data.Equals(null))

y

if (data != null)

Sin embargo, voy a recibir un NullReferenceException en dataList.Add(data). Si el objeto es nulo, nunca debería haber siquiera entrado en el if-declaración!

Por lo tanto, me estoy preguntando si esta es la correcta manera de comprobar si un objeto es null:

public List<Object> dataList;
public  bool AddData(ref Object data)
    bool success = false;
    try
    {
        //I've also used "if (data != null)" which hasn't worked either
        if (!data.Equals(null))
        {
           //NullReferenceException occurs here ...
           dataList.Add(data);
           success = doOtherStuff(data);
        }
    }
    catch (Exception e)
    {
        throw new Exception(e.ToString());
    }
    return success;
}

Si esta es la manera correcta de comprobar si el objeto es null, lo que estoy haciendo mal (¿cómo puedo evitar el procesamiento posterior en el objeto de evitar la NullReferenceException)?

  • Usted también debe usar throw e; frente a throw new Exception(e.ToString());
  • Es el data objeto inicializado antes de comprobar si el valor es nulo? O es que viene de una base de datos?
  • en C# siempre se debe utilizar la != null en su nulos cheques. .Equals siempre va a lanzar una excepción si el objeto es null.
  • throw e; no es mucho mejor. throw;, en el otro lado…
  • ¿Cuál es la razón para hacer throw e en lugar de lo que tengo? (¡Gracias!)
  • e.ToString() producirá una cadena que incluye no sólo el mensaje de error, pero también las de todos aquellos InnerExceptions y el seguimiento de la pila. Así que esa es una muy grasa pesada mensaje de excepción. Si usted (y con razón!) quiero conservar esta información, y mantener a donde pertenece, utilice simplemente throw;.
  • esa es exactamente la razón por la usted debe hacer como @Jon sugiere
  • Sólo tienes que ir con throw;
  • El try/catch no hace nada en el momento. Todo el mundo está diciendo que sólo el uso de «tirar» pero si usted no está haciendo nada con la excepción, pero la re-tirar, ¿por qué tener un bloque try/catch en todo? Por lo general, usted captura de excepciones a la gracia de manejar, limpiar los recursos (mejor con «por fin» cláusula) o hacer algún tipo de registro antes de volver a lanzar la excepción. Ninguno de estos están sucediendo en el presente código, así que no hay necesidad de try/catch en todo.
  • ¿por qué hacer pasar los datos objeto de ref ?
  • Como una pequeña actualización de C# 7 es compatible con is null, por lo que para su primer cheque que usted podría escribir if (data is null) return false; para reducir la anidación y hacer uso de la (omi) limpiador de sintaxis.

InformationsquelleAutor developer | 2011-06-20

12 Comentarios

  1. 224

    No data que es null, pero dataList.

    Usted necesita para crear uno con

    public List<Object> dataList = new List<Object>();

    Mejor aún: puesto que es un campo, hacer private. Y si no hay nada que lo impida, hacer también readonly. Sólo una buena práctica.

    A un lado

    La forma correcta de verificación para la nulidad es if(data != null). Este tipo de control es omnipresente para los tipos de referencia; incluso Nullable<T> reemplaza el operador de igualdad para ser una manera más conveniente de expresar nullable.HasValue cuando la comprobación de nulidad.

    Si usted if(!data.Equals(null)), a continuación, usted recibirá un NullReferenceException si data == null. Que es una especie de cómico puesto que para evitar esta excepción fue la meta en el primer lugar.

    Que también están haciendo esto:

    catch (Exception e)
    {
        throw new Exception(e.ToString());
    }

    Este definitivamente no es bueno. Me imagino que lo pusieron ahí sólo para que pueda entrar en el depurador, mientras que todavía en el método, en el que caso de omitir este apartado. De lo contrario, no capturar excepciones para nada. Y si no, rethrow ellas utilizando sólo throw;.

    • He visto también Objeto.ReferenceEquals(obj, null) para este propósito. Es para evitar la igualdad anula?
    • Lo he utilizado para prevenir el valor de tipo de queja cuando el uso de medicamentos genéricos: geekality.net/2009/11/13/generics-and-checking-for-null
    • Yo prefiero null != data. Colocando la constante se convierte primero el bonehead error tipográfico null = data en un error del compilador, en lugar de una involuntaria de la asignación. (También funciona para ==.)
    • En C# if (data = null) ya es un error de tiempo de compilación, por lo que incluso si se tomó décadas para llegar allí tuvimos que realmente no necesita mirar hacia fuera para eso. Incluso los compiladores de C++ se produce fácilmente una advertencia sobre posibles involuntaria de asignación para ese código.
    • Luca, también se puede evitar que la igualdad reemplaza al casting de ‘objeto’ en la prueba. En una vena similar, esta respuesta debería reclamar este lugar: «si((objeto)datos != null)», ya que evita los errores cuando la igualdad ha sido anulada.
    • Sólo para ampliar su respuesta: cada vez que usted vea un NullReferenceException, vas a ver que el null objeto es seguido por un .. El uso de que como regla general, queda claro que la excepción de datalist.Add(data) puede ser sólo sobre datalist. Comparativamente; para datalist.Add(data.Value), el problema puede ser en datalist o data. (Nota: yo no había visto que este era un hijo de 7 años de necropost. Me siento)

  2. 46

    C# 6 ha monádico comprobación de nulos 🙂

    antes:

    if (points != null) {
        var next = points.FirstOrDefault();
        if (next != null && next.X != null) return next.X;
    }   
    return -1;

    después:

    var bestValue = points?.FirstOrDefault()?.X ?? -1;
    • Porque «comentarios sólo puede ser editado por 5 minutos» ? Qué? De todos modos… Como me fue..me vino aquí en busca de una mejor sintaxis para expresar result = myObject == null ? null : myObject.SomeProperty y su ejemplo me inclinó fuera a escribir result = myObject?.SomeProperty. Hombre!! Que astuto. Todavía me encanta la codificación…
  3. 27

    Su dataList es nulo ya que no ha sido creada, a juzgar por el código que has publicado.

    Tratar:

    public List<Object> dataList = new List<Object>();
    public  bool AddData(ref Object data)
    bool success = false;
    try
    {
        if (!data.Equals(null))   //I've also used if(data != null) which hasn't worked either
        {
           dataList.Add(data);                      //NullReferenceException occurs here
           success = doOtherStuff(data);
        }
    }
    catch (Exception e)
    {
        throw new Exception(e.ToString());
    }
    return success;

    }

    • También, sólo para agregar, si los datos es null, no se bloquea, puede agregar un valor null a una Lista de<Objeto>.
    • Pero tratando de hacer .Es igual a un valor null podría lanzar una excepción. Debe hacer != null
    • Ah!! Lo que un descuido! Yo estaba pensando que el NullReferenceException fue del objeto.. no la lista! Soy nuevo en c# y pensé que había una forma especial de comprobación de null en c#!
    • Que también, pero vi a Ed S. había cubierto.
    • Gracias por el aviso. Quiero evitar a un objeto null ser añadido para su posterior procesamiento, así que voy a hacer un cheque. 🙂
    • ah ic! Voy a cambiar todos los .Equals a != null. Gracias por el aviso!
    • +1 pero he seleccionado de Jon respuesta, porque él entró en más detalles acerca de NullReferenceException. Gracias! 😀

  4. 23

    en C# 7 lo mejor es

    if (obj is null)

    De esta forma se ignora cualquier == o != definido por el objeto (a menos que, por supuesto, usted quiere hacer uso de ellos …)

    Para no igual puede if (!(obj is null)) (feo)

    • Me pregunto, ¿existe un «no nulo»? (python diría obj is not null)
    • si (!(obj es null))
    • ¿Por qué es mejor que si( obj != null ), que es más legible
    • debido a que el objeto puede reemplazar !=
  5. 17

    [Editado para reflejar la pista por @kelton52]

    Forma más sencilla es hacer object.ReferenceEquals(null, data)

    Desde (null==data) NO está garantizado para trabajar:

    class Nully
    {
        public static bool operator ==(Nully n, object o)
        {
            Console.WriteLine("Comparing '" + n + "' with '" + o + "'");
            return true;
        }
        public static bool operator !=(Nully n, object o) { return !(n==o); }
    }
    void Main()
    {
        var data = new Nully();
        Console.WriteLine(null == data);
        Console.WriteLine(object.ReferenceEquals(null, data));
    }

    Produce:

    Comparar » con ‘Nully’

    Verdadero

    Falso

    • En realidad, yo sólo traté de esto, y la mención » que implicaba La ventaja es que ignora cualquier reemplazo que pueden estar presentes en los datos de la clase, como el «operador !=».’ No parece ser cierto.
  6. 9

    No, usted debe utilizar !=. Si data en realidad es null entonces su programa bloqueará sólo con un NullReferenceException como resultado de intentar llamar a la Equals método en null. También se dan cuenta de que, si usted desea específicamente para comprobar la igualdad de referencia, debe utilizar el Object.ReferenceEquals método ya que nunca se sabe cómo Equals ha sido implementado.

    El programa se bloquea debido a dataList es nulo, ya que nunca se inicializará.

  7. 6

    El problema en este caso no es que data es nulo. Es que dataList sí mismo es nulo.

    En el lugar donde se declare dataList debe crear una nueva List objeto y asignar a la variable.

    List<object> dataList = new List<object>();
  8. 5

    Además @Jose Ortega respuesta,
    su mejor uso método de extensión

     public static bool IsNull(this object T)
         {
            return T == null;
         } 

    Y uso IsNull método para todos los de objeto como:

    object foo = new object(); //or any object from any class
    if (foo.IsNull())
       {
         //blah blah //
       }
    • Por qué return T == null ? true : false; y no sólo return T == null;?
    • Bien, puedo mejorar la respuesta..gracias.
    • No estoy seguro de que estoy de acuerdo. Parece extraño para ser una llamada a un método en un objeto para comprobar si es null. Sin saber que era un método de extensión que pensaría que podría lanzar una excepción de referencia nula.
    • Totalmente de puede confirmar que Jamie es correcta – esto no va a funcionar. Lo sé porque yo tenía un atolondrado momento y escribió una extensión similar método 😛 El código siempre echó una excepción de referencia nula, es absolutamente no va a ir en el método de extensión.
    • Realmente quiero decir que se pueden hacer thatwith extensión del método… puede ser el código tiene algún problema y se puede mejorar!
    • Usted puede llamar a un método de extensión en un objeto nulo; sólo hay que comparar T (en este caso) contra null tener cuidado. Jamie es el derecho, aunque, se ve raro.

  9. 3
      public static bool isnull(object T)
      {
          return T == null ? true : false;
      }

    uso:

    isnull(object.check.it)

    De uso condicional:

    isnull(object.check.it) ? DoWhenItsTrue : DoWhenItsFalse;

    Actualización (de otra manera) actualizado 08/31/2017. Gracias por el comentario.

    public static bool isnull(object T)
    {
        return T ? true : false;
    }
    • cond ? true : false; es completamente equivalente a tan sólo el cond. Esto no agrega nada.
    • Lo siento, pero si activas la función debe devolver un valor bool. Yo estoy haciendo el formalismo. Así que volver a facturar
    • él se refiere a return T == null; también devuelve un valor booleano!
    • Yo sé lo que hes diciendo. ty
    • En lugar de return T == null ? true : false; solo uso return T == null;.
    • ¿return T ? true : false; Realmente volver true si T es null?
    • Sí, señor, lo intente.
    • ¿por qué no object.check.it == null ? ... : ....;

  10. 2

    Jeffrey L Whitledge que es correcto. Su `dataList-Objeto en sí mismo es nulo.

    También hay otro problema con el código: Usted está utilizando el ref-palabra clave, lo que significa que el argumento de los datos no puede ser nulo! La MSDN dice:

    Un argumento que se pasa a un parámetro de referencia en primer lugar debe ser inicializado. Esto difiere de lo que fuera, cuyos argumentos no tiene que inicializarse explícitamente antes de que pasen

    Que también no es una buena idea el uso de medicamentos genéricos con el tipo de Objeto. Los medicamentos genéricos deben evitar boxing/unboxing y también garantizar la seguridad de tipos. Si desea un tipo común de hacer de su método genérico. Finalmente, el código debe tener este aspecto:

    public class Foo<T> where T : MyTypeOrInterface {
    
          public List<T> dataList = new List<T>();
    
          public bool AddData(ref T data) {
            bool success = false;
            try {
              dataList.Add(data);                   
              success = doOtherStuff(data);
            } catch (Exception e) {
              throw new Exception(e.ToString());
            }
            return success;
          }
    
          private bool doOtherStuff(T data) {
            //...
          }
        }
  11. 2

    Como otros ya han señalado, no data sino probable dataList que es null. Además…

    catchthrow es un antipattern que casi siempre me dan ganas de vomitar cada vez que la veo. Imagino que algo va mal profundo en algo que doOtherStuff() llamadas. Todo lo que obtiene es un Exception objeto, lanzado en el throw en AddData(). No hay traza de la pila, no hay información de llamada, ningún estado, nada en absoluto se indique el verdadero origen del problema, a menos que vaya en y encienda el depurador de descanso en la excepción más que la excepción no controlada. Si se captura una excepción y sólo re-tirar de alguna manera, especialmente si el código del bloque try es de ninguna manera trivial, ¿ a usted (y sus colegas, el presente y el futuro) un favor y tirar toda la trycatch bloque. Concedido, throw; es mejor que las alternativas, pero todavía se está dando a sí mismo (o a quienquiera se está tratando de corregir un error en el código) completamente innecesarios dolores de cabeza. Esto no quiere decir que try-catch-tiro es necesariamente malo per se, siempre y cuando usted hacer algo relevante con el objeto de excepción que fue lanzado en el bloque catch.

    A continuación, existe la posibilidad de problemas de la captura de Exception en el primer lugar, pero eso es otro asunto, en particular, ya que en este caso particular, se lanzará una excepción.

    Otra cosa que me llama la atención como algo más que un poco peligroso es que data podría potencialmente cambiar de valor durante la ejecución de la función, ya que se pasa por referencia. Para la verificación null podría pasar, pero antes de que el código va a hacer nada con el valor, lo que ha cambiado, tal vez para null. No estoy seguro si esto es una preocupación o no (puede que no), pero parece que vale la pena mirar hacia fuera para.

  12. 1

    Siempre se están creando objetos de la clase que usted tiene que comprobar si el objeto es null o no usar el siguiente código.

    Ejemplo:
    objeto1 es un objeto de la clase

    void myFunction(object1)
    {
      if(object1!=null)
      {
         object1.value1 //If we miss the null check then here we get the Null Reference exception
      }
    }

Dejar respuesta

Please enter your comment!
Please enter your name here