13 ms·

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

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?;

recursive 6y ago
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.
- 737maxtw 6y ago
  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.
  - recursive 6y ago
    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.
- manigandham 6y ago
  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.
  - recursive 6y ago
    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);

recursive 6y ago

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.

737maxtw 6y ago
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.
- recursive 6y ago
  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.
manigandham 6y ago
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.
- recursive 6y ago
  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);