validar fecha null en c#

Comprobando si un objeto es nulo en C#

Question

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

En el siguiente código, compruebo si el objeto es nulo:

if (!data.Equals(null))

y

if (data != null)

Sin embargo, recibo una NullReferenceException en dataList.Add(data) . Si el objeto era nulo, ¡nunca debería haber ingresado siquiera en la declaración if !

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

Answer 1

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 método IsNull para todos los objetos como:

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

Answer 2

C # 6 tiene 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;

Answer 3

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

catch - throw es un antipattern que casi siempre me da ganas de vomitar cada vez que lo veo. Imagine que algo sale mal en algo que doOtherStuff() llama. Todo lo que obtienes es un objeto Exception , arrojado al throw en AddData() . Sin seguimiento de pila, sin información de llamada, sin estado, nada en absoluto para indicar el origen 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 está atrapando una excepción y solo volviéndola a lanzar de cualquier forma , particularmente si el código en el bloque try es de alguna manera no trivial, hágase a usted mismo (y a sus colegas, presente y futuro) un favor y deseche todo el try - catch bloque De acuerdo, throw; es mejor que las alternativas, pero aún te estás dando (o a quien sea que intente arreglar un error en el código) dolores de cabeza completamente innecesarios. Esto no quiere decir que try-catch-throw sea necesariamente per se, siempre y cuando haga algo relevante con el objeto de excepción que se lanzó dentro del bloque catch.

Luego están los problemas potenciales de capturar Exception en primer lugar, pero ese es otro asunto, particularmente porque en este caso particular arrojas una excepción.

Otra cosa que me parece más que un poco peligrosa es que los data podrían potencialmente cambiar el valor durante la ejecución de la función, ya que está pasando por referencia. Así que la verificación nula podría pasar, pero antes de que el código llegue a hacer algo con el valor, ha cambiado, tal vez a null . No estoy seguro si esto es una preocupación o no (podría no serlo), pero parece que vale la pena estar atento.

Answer 4

El problema en este caso no es que los data sean nulos. Es que dataList sí es nulo.

En el lugar donde declaras dataList debes crear un nuevo objeto List y asignarlo a la variable.

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

Answer 5

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. MSDN dice:

Un argumento pasado a un parámetro ref primero debe inicializarse. Esto difiere de out, cuyos argumentos no tienen que inicializarse explícitamente antes de pasarlos

Tampoco es una buena idea usar genéricos con el tipo `Object ''. Los genéricos deben evitar el boxeo / unboxing 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) {
//...
}
}

Answer 6

No son data null , sino dataList .

Necesitas crear uno con

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

Aún mejor: ya que es un campo, hazlo private . Y si no hay nada que lo readonly , readonly también de manera readonly . Solo una buena práctica.

Aparte

La forma correcta de verificar la nulidad es if(data != null) . Este tipo de control es omnipresente para los tipos de referencia; incluso Nullable<T> anula el operador de igualdad para que sea una forma más conveniente de expresar nullable.HasValue al verificar la nulidad.

Si lo hace if(!data.Equals(null)) obtendrá una NullReferenceException si data == null . Lo cual es algo cómico ya que evitar esta excepción fue el objetivo en primer lugar.

Usted también está 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 en el depurador mientras estás dentro del método, en cuyo caso ignora este párrafo. De lo contrario, no atrape excepciones por nada. Y si lo haces, vuelve a throw; con solo throw; .

Answer 7

No, deberías estar usando != . Si los data son realmente nulos, su programa se bloqueará con una NullReferenceException como resultado de intentar llamar al método Equals en null . Además, tenga en cuenta que, si desea comprobar específicamente la igualdad de referencia, debe utilizar el método Object.ReferenceEquals ya que nunca se sabe cómo se ha implementado Equals .

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

Answer 8

Siempre que cree objetos de clase, debe verificar si el objeto es nulo o no utiliza el código siguiente.

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
}
}

Answer 9

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;

}

Answer 10

[Editado para reflejar la pista de @ kelton52]

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

Dado que (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

Answer 11

 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 el 31/08/2017. Gracias por el comentario.

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