Why have a DBNull?

[Bob]

I'm sure there's a good reason, I just haven't been able to think of it -
why didn't MS allow "DBNull" values to simply be a null (Nothing)?

Bob

 

[Herfried K. Wagner [MVP]]

I'm sure there's a good reason, I just haven't been able to think of it -
why didn't MS allow "DBNull" values to simply be a null (Nothing)?

Can you show a sample where 'Nothing' is treated as 'DBNull'?

 

[Jay B. Harlow [MVP - Outlook]]

Bob,
It allows DBNull to be treated differently then Nothing.

For example DataRowCollection.Add uses "Nothing" to mean set the column to
its Default value, while it uses DBNull to mean set it to a Database Null.

http://msdn.microsoft.com/library/d...systemdatadatarowcollectionclassaddtopic2.asp

Hope this helps
Jay

 

[Guest]

I think the question was why do we have to contend with DBNull and
Nothing..why can't they be treated the same in code so you don't have to
check for something being a dbnull as well as nothing. To go farther, why
doesn't a string variable used like b.Trim return nothing when b is nothing
instead of an exception? Everytime you want to trim a string, you have to
check it for being nothing unless you use the Trim function from Microsoft
Visual Basic name space.

 

[Jay B. Harlow [MVP - Outlook]]

Dennis,
As I stated it allows DBNull to be treated differently then Nothing. A
second reason is to allow your code to avoid Nothing itself.

Remember DBNull is simply an implementation of the Special Case pattern.

http://martinfowler.com/eaaCatalog/specialCase.html

It allows you to write code that you know will always have a value, so you
are able to call any of its base methods (in this case Object).

For example I know I can call ToString on each value returned from
DataRow.Item() as those items will never be Nothing. If one of the values
could be Nothing I would need special case code to call Object.ToString...
Yes DBNull may require special case codes in spots, I'm not disputing
that...

To go farther, why
doesn't a string variable used like b.Trim return nothing when b is
nothing
instead of an exception?

Unlike C++, VB.NET & C# requires an object be present when you call an
instance method on that object. IMHO at a certain "OO" level it doesn't
really make sense to ask an object to perform some behavior when there is no
object there to ask do to anything...

Unmanaged C++ (I'm not sure about managed C++) does allow calling instance
methods on null (Nothing) pointers causing this (Me) to be null (Nothing).
However it normally required a lot of "AssertValid" macros in your code to
ensure that you actually have an object that you are calling a method on. In
other words 99% or better of code requires a valid object, and one or two
methods could benefit from being Nothing...

Everytime you want to trim a string, you have to
check it for being nothing unless

I rarely check a variable for being nothing before I call instance methods &
I rarely receive NullReferenceExceptions, as I make sure variables are
initialized, I normally have strategic Guard conditions or use the Null
Object Pattern to prevent variables from being Nothing. This is not to say I
don't receive NullReferenceExceptions during development, its just that they
are "limited"...

Current versions of C# & VB.NET 2005 will issue compile warnings if you try
to call an instance method on an un-initialized variable (the most common
reason for NullReferenceExceptions).

Hope this helps
Jay

 

[Cor Ligthert]

Dennis,

Why are there from almost all living creatures on earth a man and a woman.

My expirience is that it is very difficult to change behaviours back in time
and often there is a good reason to let it as it is.

))

Cor

 

[Stephany Young]

So that the woman can tell the man what to do

 

[David]

To go farther, why
doesn't a string variable used like b.Trim return nothing when b is nothing
instead of an exception? Everytime you want to trim a string, you have to
check it for being nothing unless you use the Trim function from Microsoft
Visual Basic name space.

That's a good question, actually, and it goes deep into different
approaches to programming, and why some people find much of the VB
namespace along with VB's special-casing of string operators dangerous
while others find it indispensable.

On the one side is the ease-of-use crowd, asking questions like the one
above. If a string is Nothing, there's no reason that string functions
can't return something reasonable. And generally they're absolutely
right, since there's almost always a reasonable semantic equivalence
between Nothing and String.Empty.

On the flipside of the question is a completely different way of looking
at the problem. The question here is why am I dealing with an
uninitialized string, and why is the runtime hiding that from me? If a
string is Nothing when it shouldn't be, that's usually the result of
deeper design issues, and I want to know about it as early in
development as possible. The fact that Trim() hides this fact from me
is an error in design, not a feature.

And in a well-designed program, if a value should never be Nothing, a
check for that is limited to IO classes, not spread throughout the
program.

VB.Classic tended to adhere to the former point of view, C++/Java to the
latter point of view. Since .Net was geared more towards the C++/Java
crowd, the core framework throws on Nothing, while the VB namespace and
VB.Net itself often treats empty strings and null strings equivalently.

 

[Bob]

That would seem to be to be poor design. It would have been better to have
to use something like "DBDefault.Value" to make it clear what will happen.
Nothing can never be found in actual table data, so allowing Nothing is this
case is also inconsistent and confusing.

Bob

 

[Bob]

On the flipside of the question is a completely different way of looking
at the problem. The question here is why am I dealing with an
uninitialized string, and why is the runtime hiding that from me? If a
string is Nothing when it shouldn't be, that's usually the result of
deeper design issues, and I want to know about it as early in
development as possible. The fact that Trim() hides this fact from me
is an error in design, not a feature.

And in a well-designed program, if a value should never be Nothing, a
check for that is limited to IO classes, not spread throughout the
program.

<...>

I personally have never come across a case when it was useful for me to have
a String as Nothing instead of "". I wish they had made String a structure,
although I'm sure there are some fundamental reasons why it isn't.

Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob
| Nothing can never be found in actual table data
That's the entire point being have DBNull! Nothing itself is not allowed in
the table data itself!

| , so allowing Nothing is this
| case is also inconsistent and confusing.
I agree, the only thing that Nothing saves here is defining a second Special
Case pattern object (DBDefault). I too wonder if its worth saving defining
DBDefault?

However! Rather then define both DBNull & DBDefault types, I would consider
defining a single DBValue type & have 2 fields on it DBValue.Null &
DBValue.Default.

Hope this helps
Jay

| That would seem to be to be poor design. It would have been better to have
| to use something like "DBDefault.Value" to make it clear what will happen.
| Nothing can never be found in actual table data, so allowing Nothing is
this
| case is also inconsistent and confusing.
|
| Bob
|
| | > Bob,
| > It allows DBNull to be treated differently then Nothing.
| >
| > For example DataRowCollection.Add uses "Nothing" to mean set the column
to
| > its Default value, while it uses DBNull to mean set it to a Database
Null.
| >
| >
|
http://msdn.microsoft.com/library/d...systemdatadatarowcollectionclassaddtopic2.asp
| >
| > Hope this helps
| > Jay
|
|