Nullable<bool> usage guideline

re: Nullable usage guideline

joshwil — Fri, 27 Apr 2007 18:34:57 GMT

The example given seems like a perfect excuse to return an enum.

re: Nullable usage guideline

JoshCh — Fri, 27 Apr 2007 20:21:48 GMT

How about getting ADO.NET to properly support nullable types? It would save a ton of a code to be able to have the DBNull.Value handled as a normal null in the following case:

long? id = (long?)dataReader["id"];

If dataReader["id"] is DBNull, id gets set to null. This way nullables become much more useful.

re: Nullable usage guideline

Michael Neel — Sat, 28 Apr 2007 00:19:48 GMT

No, no and no. No.

Oracle does this - conditions can return true, false, or null (if a value in the expression was null). This is one of those things that lead to weird bugs you don't expect - and isn't often thought of in the first round of unit tests.

If you have a third meaning, make an Enum so it's clear what the three states mean.

re: Nullable usage guideline

Richard — Sun, 29 Apr 2007 11:40:35 GMT

Only if the third value is FileNotFound.

http://worsethanfailure.com/Articles/What_Is_Truth_0x3f_.aspx

re: Nullable usage guideline

Thanuja — Thu, 10 May 2007 12:03:35 GMT

Well in the attribute example i think if the attribute is not found you should return and exception as it is an impt info for the upper layers(if layered patterned is used)

re: Nullable usage guideline

Andrei Rinea — Tue, 20 May 2008 01:49:58 GMT

@JoshCh:

Regarding :

long? id = (long?)dataReader["id"];

are you sure if dataReader["id"] is going to be DBNull.Value (the sole instance of the DBNull class) then it will be castable to "long?"? As far as I know that will throw an InvalidCastException.