Comprobando si un objeto es nulo en C #

Me gustaría evitar un mayor procesamiento en un objeto si es nulo.

En el siguiente código verifico si el objeto es nulo por cualquiera de los dos:

if (!data.Equals(null))

y

if (data != null)

Sin embargo, recibo un NullReferenceExceptionat dataList.Add(data). Si el objeto era nulo, ¡nunca debería haber ingresado en la ifdeclaración!

Por lo tanto, pregunto si esta es la forma correcta de verificar si un objeto es nulo:

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 forma correcta de verificar si el objeto es nulo, ¿qué estoy haciendo mal (¿cómo puedo evitar un mayor procesamiento en el objeto para evitar la NullReferenceException)?

No es dataeso null, pero dataList.

Necesitas crear uno con

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

Aún mejor: como es un campo, hazlo private. Y si no hay nada que te impida, hazlo también readonly. Solo una buena práctica.

Aparte

La forma correcta de verificar la nulidad es if(data != null). Este tipo de verificación es omnipresente para los tipos de referencia; incluso Nullable<T>anula el operador de igualdad para ser una forma más conveniente de expresar nullable.HasValuecuando se verifica la nulidad.

Si lo haces if(!data.Equals(null)), obtendrás un NullReferenceExceptionif data == null. Lo cual es bastante cómico ya que evitar esta excepción fue el objetivo en primer lugar.

También estás haciendo esto:

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

Esto definitivamente no es bueno. Me imagino que lo pones allí solo para que puedas entrar al depurador mientras aún estás dentro del método, en cuyo caso ignora este párrafo. De lo contrario, no atrape excepciones para nada. Y si lo hace, vuelva a lanzarlos usando solo throw;.

en C #> 7.0 uso

if (obj is null) ...

Esto ignorará cualquier == o! = Definido por el objeto (a menos, por supuesto, que desee usarlos ...)

Para uso no nulo if (obj is object)(o if (!(obj is null)))

C # 6 tiene una comprobación nula monádica :)

antes de:

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;

Su dataList es nula ya que no se ha instanciado, a juzgar por el código que ha 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;

}

[Editado para reflejar una pista de @ kelton52]

La manera más simple es hacer object.ReferenceEquals(null, data)

Como (null==data)NO se garantiza que funcione:

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:

Comparando '' con 'Nully'

Cierto

Falso

No, deberías estar usando !=. Si datarealmente es nulo, entonces su programa simplemente se bloqueará con un NullReferenceExceptioncomo resultado de intentar activar el Equalsmétodo null. También tenga en cuenta que, si desea verificar específicamente la igualdad de referencia, debe usar el Object.ReferenceEqualsmétodo ya que nunca sabe cómo Equalsse ha implementado.

Su programa se bloquea porque dataListes nulo ya que nunca lo inicializa.

El problema en este caso no dataes que sea ​​nulo. Es que en dataListsí mismo es nulo.

En el lugar donde declara dataList, debe crear un nuevo Listobjeto y asignarlo a la variable.

List<object> dataList = new List<object>();

Además de la respuesta de @Jose Ortega , es mejor usar el método de extensión

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

Y use el IsNullmétodo para todos los objetos como:

object foo = new object(); //or any object from any class
if (foo.IsNull())
   {
     // blah blah //
   }

A partir de C # 8 , puede usar el patrón de propiedad 'vacío' (con coincidencia de patrones ) para asegurarse de que un objeto no sea nulo:

if (obj is { })
{
    // 'obj' is not null here
}

Este enfoque significa " si el objeto hace referencia a una instancia de algo " (es decir, no es nulo).

Se puede pensar en esto como lo opuesto a: if (obj is null).... que devolverá verdadero cuando el objeto no haga referencia a una instancia de algo.

Para obtener más información sobre patrones en C # 8.0, lea aquí .

A partir de C # 9 puedes hacer

if (obj is null) { ... }

Para uso no nulo

if (obj is not object) { ... }

Si necesita anular este comportamiento, use ==y en !=consecuencia.

Jeffrey L Whitledge tiene razón. Su `dataList´-Object en sí mismo es nulo.

También hay otro problema con su código: está utilizando la palabra clave ref, lo que significa que los datos del argumento no pueden ser nulos. El MSDN dice:

Primero se debe inicializar un argumento pasado a un parámetro ref. Esto difiere de fuera, cuyos argumentos no tienen que inicializarse explícitamente antes de pasarlos

Tampoco es una buena idea usar genéricos con el tipo `Objeto´. Los genéricos deben evitar el boxeo / desempaquetado y también garantizar la seguridad del tipo. Si desea un tipo común, haga que su método sea genérico. Finalmente su código debería verse así:

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) {
        //...
      }
    }

Como otros ya han señalado, no lo es, datapero es muy probable dataListque así sea null. Además de eso...

catch- throwEs un antipatrón que casi siempre me da ganas de vomitar cada vez que lo veo. Imagina que algo sale mal en algo que doOtherStuff()llama. Todo lo que se obtiene es un Exceptionobjeto, lanzado en el throwen AddData(). Sin seguimiento de la pila, sin información de llamadas, sin estado, nada en absoluto para indicar la fuente real del problema, a menos que entre y cambie su depurador para interrumpir la excepción lanzada en lugar de la excepción no controlada. Si tienes que coger una excepción y sólo re-lanzando que de ninguna manera , sobre todo si el código en el bloque try es de ninguna manera no trivial, hacer usted mismo (y sus colegas, presente y futuro) un favor y echar un vistazo a la totalidad try- catchbloque . Concedido,throw;es mejor que las alternativas, pero todavía te estás dando a ti mismo (o a quien sea que esté tratando de corregir un error en el código) dolores de cabeza completamente innecesarios. Esto no quiere decir que try-catch-throw sea necesariamente malo per se, siempre que haga algo relevante con el objeto de excepción que se arrojó dentro del bloque catch.

Luego están los posibles problemas de la captura Exceptionen primer lugar, pero ese es otro asunto, particularmente porque en este caso particular lanzas una excepción.

Otra cosa que me parece más que un poco peligrosa es que datapotencialmente podría cambiar el valor durante la ejecución de la función, ya que está pasando por referencia. Por lo tanto, la verificación nula puede pasar, pero antes de que el código haga algo con el valor, cambia, quizás a null. No estoy seguro de si esto es una preocupación o no (puede que no lo sea), pero parece que vale la pena tenerlo en cuenta.

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

utilizar:

isnull(object.check.it)

Uso condicional:

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

Actualización (otra forma) actualizada 31/08/2017. Gracias por el comentario.

public static bool isnull(object T)
{
    return T ? true : false;
}

Siempre que esté creando objetos de clase, debe verificar si el objeto es nulo o no utilizando el siguiente código.

Ejemplo: object1 es objeto de clase

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

Simplemente seguí un método que generalmente seguiríamos en Java Script. Para convertir objetos en cadenas y luego verificar si son nulos.

var obj = new Object();
var objStr = obj.ToString();
if (!string.IsNullOrEmpty(objStr)){
  // code as per your needs
}

Lo hice más simple (forma positiva) y parece funcionar bien.

Dado que cualquier tipo de "objeto" es al menos un objeto

    if (MyObj is Object)
    {
            //Do something .... for example:  
            if (MyObj is Button)
                MyObj.Enabled = true;
    }