Null.La historia interminable(1/3)

Esta mañana y después de ver esta entrada en el foro de c# Obtener los registros de una tabla como objetos y guardarlos en una lista y más concretamente estas líneas de código.

   1: object fechaNacim = reader["FechaNacim"];

   2: FechaNacimiento = fechaNacim == DBNull.Value ? null : (DateTime)fechaNacim;

Me han llegado a la cabeza recuerdos del pasado, mucho antes de la existencia de .Net. Os acordáis de ese error típico de las aplicaciones vb “error 91 object variable or with block variable not set”. Y después muerte. Pues ha llovido, pero lo seguimos teniendo presente en nuestras vidas.

Después de citar al viejo vb donde esto se solucionaba con esto

   1: if isnull(ADODC.Recordset.Fields("Cod_Localidad")) then

   2: end if

avanzamos en el tiempo y nos encontramos en la misma o parecida situación un null de la bb.dd nos ocasiona y no pocos problemas.

Si nos situamos en el año 2002 aparece un nuevo señor para solucionarnos el problema DBNull.Value, que pasada. Ya no aparece el error 91 pero si FormatException.

   1: var ValorBd = System.DBNull.Value;

   2: int Valor = int.Parse(ValorBd.ToString())

Y también  SqlNullValueException.

   1: using (SqlConnection cn = new SqlConnection(@"<Cadena de Conexion>"))

   2: {

   3:        cn.Open();

   4:        SqlCommand cmd = new SqlCommand("SELECT CAST(NULL AS INT)",cn);

   5:        SqlDataReader reader = cmd.ExecuteReader();

   6:        while(reader.Read())

   7:        {                    

   8:            int Valor = reader.GetInt32(0);

   9:        }

  10: }

y en vez de tener un premio que era lo que se conseguía antes de .Net obtenemos dos.

Bueno como una de nuestras virtudes es la paciencia  esperamos a 2005 y aparece una de las maravillas del Framework 2.0 System.Nullable<T> o para quien más le guste “?” detrás del tipo, parece que el problema está solucionado, pero no,  simplemente con profundizar un poco nos damos cuenta que las clases del namespace System.Data se han quedado igual y es por eso por lo que esta mañana para leer un null  nos encontramos con las primeras líneas de código de este post.

Seguimos avanzando años y vemos que ese problema parece que se va a convertir en un mal menor con la aparición de Entity Framework y la realidad que así es, pero sigue sin ser perfecto.

Si reflexionamos han pasado por lo menos para mí 20 años y seguimos pensado en Null.

Bueno he de reconocer que desde 2005 yo deje de pensar en el y eso es material para el próximo post o mejor dicho un capitulo más de esta historia.

Próximos capítulos.

Como puedo vivir mejor con Null sino utilizo Entity Framework.

Que le falta a EF desde mi punto de vista para de una vez olvidarnos del Null.

Como una de las cosas que más me gusta es el debate vamos a empezar con un aperitivo. ¿Debería string tener un tipo Nullable o lo que es lo mismo declarar este como “?string” ?

Espero que os haya gustado y sobre todo espero vuestra reflexión acerca de la pregunta.

6 comentarios sobre “Null.La historia interminable(1/3)”

  1. >Debería string tener un tipo Nullable o lo que es lo mismo declarar este como “?string”

    No.
    Nullable sobre strings no tiene sentido, los strings son nullables por definición.

    string s = null; // 😉
    AAAhhh… el problema es que null y DbNull no es lo mismo.

    Sí, hay un follón entre el null del CLR y el NULL de la Base de datos, pero agregar *otro* null al CLR no es, ni de lejos, la solución…

    Saludos!

  2. Hola!

    Como dice Eduard, los nullables sólo tienen sentido con tipos valor (int, byte, long, decimal…), pues en los tipos referencia como string es perfectamente válido.

    La convivencia con nulos ha sido siempre difícil. Personalmente, sí me sentí algo aliviado con la llegada de los tipos anulables, porque aunque tuviera que realizar adaptaciones para traspasar las fronteras (CLR->BDD o viceversa), al menos me permitían representar en memoria, y de forma más natural y cercana, el contenido existente en el almacén de datos.

    En cualquier caso, ya con los ORM parece que la cosa va mejorando 🙂

    Saludos.

  3. Hola

    Eduard y Jose María coincido con lo que estáis comentando pero menudo dolor de cabeza gestionar si un string es null o no es null, vamos a pensar casi 20 años conviviendo con el problema, tendrá solucion?.

    Decidme los dos si no habéis pensado y deseadeo encontraros con un string o sucedaneo que al asignar null el compilador diese un error.

    Vamos por buen camino:)

    Saludos

  4. Las referencias null se incorporaron en ALGOL. En el 2009 su creador, Tony Hoare declaró que eran el error del billón de dolares (seguramente un billón americano, pero bueno).
    En este video (http://geeks.ms/blogs/lontivero/archive/2012/02/02/c-243-digo-libre-de-nulls.aspx) explica bastante bien el tema de los nulls, su problemática y como se puede luchar contra esto…

    Si me hubiese gustado que al asignar null diese error? Pues sí, al igual que me hubiese gustado que el diseño por contratos fuese una parte integral del lenguaje, pero esto es lo que hay… 😉

    Saludos!

  5. Hola Eduard,

    Había visto el video de Lucas Ontivero y la verdad que buenísimo y sobre todo los comentarios:). Pero no me refería a ese null que viene porque lógicamente hay un error en la introducción de datos o bien el Customer como cita en este ejemplo ha sido eliminado.

    e refería a otra cosa, que los tipos nativos al mapearlos desde la bb.dd están mas o menos bien representados con la aparición de los Nullables, pero uno y que por desgracia es el que más usamos en nuestras app no está bien representado y ese es string. Es por eso por lo hice esa pregunta en el post:)

Responder a pedrohurtado Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *