Verificando se um objeto é nulo em C #

Eu gostaria de impedir um processamento adicional em um objeto se ele for nulo.

No código a seguir, verifico se o objeto é nulo por:

if (!data.Equals(null))

e

if (data != null)

No entanto, recebo um NullReferenceExceptionem dataList.Add(data). Se o objeto fosse nulo, ele nunca deveria ter inserido a ifinstrução-!

Portanto, estou perguntando se essa é a maneira correta de verificar se um objeto é 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;
}

Se esta é a maneira correta de verificar se o objeto é nulo, o que estou fazendo de errado (como posso impedir um processamento adicional no objeto para evitar a NullReferenceException)?

Não é dataisso null, mas dataList.

Você precisa criar um com

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

Ainda melhor: como é um campo, faça-o private. E se não houver nada impedindo você, faça isso também readonly. Apenas boas práticas.

a parte, de lado

A maneira correta de verificar a nulidade é if(data != null). Esse tipo de verificação é onipresente para tipos de referência; até Nullable<T>substitui o operador de igualdade por ser uma maneira mais conveniente de expressarnullable.HasValue ao verificar a nulidade.

Se você o fizer if(!data.Equals(null)), receberá um NullReferenceExceptionifdata == null . O que é meio cômico, já que evitar essa exceção era o objetivo em primeiro lugar.

Você também está fazendo isso:

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

Definitivamente, isso não é bom. Eu posso imaginar que você o coloque lá apenas para poder entrar no depurador enquanto ainda estiver dentro do método; nesse caso, ignore este parágrafo. Caso contrário, não pegue exceções por nada. E se o fizer, repita-as usando apenas throw;.

em C #> 7.0 use

if (obj is null) ...

Isso ignorará qualquer == ou! = Definido pelo objeto (a menos que você queira usá-lo ...)

Para uso não nulo if (obj is object)(ou if (!(obj is null)))

C # 6 tem verificação nula monádica :)

antes:

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

depois de:

var bestValue = points?.FirstOrDefault()?.X ?? -1;

Seu dataList é nulo, pois não foi instanciado, a julgar pelo código que você postou.

Experimentar:

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 refletir a dica de @ kelton52]

Maneira mais simples é fazer object.ReferenceEquals(null, data)

Como (null==data)NÃO é garantido 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));
}

Produz:

Comparando '' com 'Nully'

Verdade

Falso

Não, você deveria estar usando !=. Se, datana verdade, for nulo, seu programa irá travar com NullReferenceExceptionum resultado da tentativa de chamar o Equalsmétodo null. Perceba também que, se você deseja verificar especificamente a igualdade de referência, deve usar o Object.ReferenceEqualsmétodo como nunca sabe como Equalsfoi implementado.

Seu programa está travando porque dataListé nulo, pois você nunca o inicializa.

O problema neste caso não dataé que seja nulo. É que dataListele próprio é nulo.

No local em que você declara, dataListvocê deve criar um novo Listobjeto e atribuí-lo à variável.

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

Além da resposta de Joseph Ortega , é melhor usar o método de extensão

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

E use o IsNullmétodo para todos os objetos como:

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

A partir do C # 8, você pode usar o padrão de propriedade 'vazio' (com correspondência de padrão ) para garantir que um objeto seja não nulo:

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

Essa abordagem significa " se o objeto faz referência a uma instância de algo " (ou seja, não é nulo).

Você pode pensar nisso como o oposto de: if (obj is null)... . que retornará true quando o objeto não fizer referência a uma instância de algo.

Para mais informações sobre padrões em C # 8.0, leia aqui .

A partir do C # 9, você pode fazer

if (obj is null) { ... }

Para uso não nulo

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

Se você precisar substituir esse comportamento, use ==e de !=acordo.

Jeffrey L. Whitledge está certo. Seu próprio objeto `dataList´ é nulo.

Também há outro problema com o seu código: você está usando a palavra-chave ref, o que significa que os dados do argumento não podem ser nulos! O MSDN diz:

Um argumento passado para um parâmetro ref deve primeiro ser inicializado. Isso difere de fora, cujos argumentos não precisam ser explicitamente inicializados antes de serem passados

Também não é uma boa ideia usar genéricos com o tipo `Objeto '. Os genéricos devem evitar o boxe / desembalagem e também garantir a segurança do tipo. Se você deseja um tipo comum, torne seu método genérico. Finalmente, seu código deve ficar assim:

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 outros já apontaram, não é, datamas é bem provável dataListque seja null. Além disso...

catch- throwé um antipadrão que quase sempre me dá vontade de vomitar toda vez que o vejo. Imagine que algo dê errado no fundo de algo que doOtherStuff()chama. Tudo o que você recebe de volta é um Exceptionobjeto, jogado throwna entrada AddData(). Sem rastreamento de pilha, sem informações de chamada, sem estado, nada para indicar a fonte real do problema, a menos que você entre e alterne seu depurador para interromper a exceção lançada em vez da exceção não tratada. Se você está capturando uma exceção e apenas a reproduzindo de alguma forma , principalmente se o código no bloco try não for trivial, faça um favor a si mesmo (e a seus colegas, presente e futuro) e jogue fora todotry - catchbloco . Concedido,throw;é melhor do que as alternativas, mas você ainda está dando a si mesmo (ou a quem quer que esteja tentando corrigir um bug no código) dores de cabeça completamente desnecessárias. Isso não quer dizer que o try-catch-throw seja necessariamente ruim por si só, desde que você faça algo relevante com o objeto de exceção lançado dentro do bloco catch.

Depois, existem os possíveis problemas de captura Exceptionem primeiro lugar, mas isso é outra questão, principalmente porque nesse caso em particular você lança uma exceção.

Outra coisa que me parece mais do que um pouco perigosa é que datapoderia potencialmente alterar valor durante a execução da função, já que você está passando por referência. Portanto, a verificação nula pode passar, mas antes que o código faça algo com o valor, ele é alterado - talvez para null. Não tenho certeza se isso é uma preocupação ou não (pode não ser), mas parece que vale a pena prestar atenção.

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

usar:

isnull(object.check.it)

Uso condicional:

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

Atualização (outra maneira) atualizada em 31/08/2017. Obrigado pelo comentário.

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

Sempre que você estiver criando objetos da classe, verifique se o objeto é nulo ou não usando o código abaixo.

Exemplo: object1 é objeto da classe

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

Eu apenas segui um método que normalmente seguiríamos no script java. Para converter objeto em string e verifique se eles são nulos.

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

Eu fiz mais simples (maneira positiva) e parece funcionar bem.

Como qualquer tipo de "objeto" é pelo menos um objeto

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