Hacker News Reader

Comment by manigandham | Hacker News Reader

If you're talking about value types then nullable value types exist, which are still structs:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

None of that helps. A nullable int is `Nullable<int>` or `int?` for short. There is nothing about the language feature that allows you to represent null with a totally different type like `DBNull`, other than declaring your variable `object`. What's the return type of a method that sometimes returns `int` and sometimes `DBNull`? It can only be `object`.

I seem to be having some trouble explaining my point. Maybe this will illustrate better. What should be the declared return type of this method?

    ??? GetValue() {
        if (condition) {
            return 7;
        }
        else {
            return DBNull.Value;
        }
    }

Why do you need to represent `null` with another type? Is this just an issue with DB query results? You can avoid it by making sure the query never returns null or read the values yourself using a type cast test:

int? someNumber = resultset.Records[0]["some_column"] as int?;

Somehow we've gone full circle, and you're arguing my position back to me.

That code sample is exactly how I'd write it. My only problem is that DBNull ever existed in the first place.

There's a difference in certain contexts between 'null' (i.e., a reader that is not initialized) versus DBNull (the value has been set as null by the db or something else). I still think its technically correct.

I get that it was annoying, but most of .NET before 3.5 was anyway. It's just nobody bothered to make the right syntactic sugar.

For callers that care about the distinction, there should (IMHO) have been a GetNullFlavor(). Personally, the number of times I've actually cared is indistinguishable from zero. But the number of times I've had to deal with the infectious stench of DBNull is higher than zero.

Yes, I have a point of view.

My point is that DBNull is only an edge case with DB queries. You can avoid ever dealing with it as I've shown or use an ORM like Dapper or Entity Framework that also handle it for you.

There's really no reason why you have to touch DBNull at all.

I really wish that were true. DBNull is in third-party libraries. And first- and second- too. Check out this code. Dot net really wants me to use DBNull. No database in play at all.

  var dt = new DataTable();
  dt.Columns.Add("name", typeof(string));
  //dt.Columns.Add("count", typeof(int?)); // NotSupportedException: DataSet does not support System.Nullable<>.
  dt.Columns.Add("count", typeof(int));
  var row=dt.NewRow();
  row["name"] = null;
  //row["count"] = null; // ArgumentException: Cannot set Column 'count' to be null. Please use DBNull instead.
  row["count"] = DBNull.Value;
  dt.Rows.Add(row);

Reply on news.ycombinator.com