Dealing with Null Values

  • Thread starter Thread starter Max Sandman
  • Start date Start date
M

Max Sandman

I'm getting increasingly frustrated with C# and its exceptions on null
values. Rather than try to deal with it on a hit-or-miss basis as
exceptions pop up, I thought I should try to learn exactly how C# deals
with null. Of course, there's nothing obvious in the docs like "Dealing
with Null Values" and a search on "null" yielded 500 results, most of
which don't apply. Can anybody point me in the right direction? Or offer
some general guidelines? Or even the correct keyword to search the docs?

sandman
 
Max Sandman said:
I'm getting increasingly frustrated with C# and its exceptions on null
values. Rather than try to deal with it on a hit-or-miss basis as
exceptions pop up, I thought I should try to learn exactly how C# deals
with null. Of course, there's nothing obvious in the docs like "Dealing
with Null Values" and a search on "null" yielded 500 results, most of
which don't apply. Can anybody point me in the right direction? Or offer
some general guidelines? Or even the correct keyword to search the docs?
Click to expand...

Never try to dereference null - that's when you'll get an exception.

Read the documentation for methods you call - they should (but probably
won't always, unfortunately) specify whether or not null is a valid
value for the parameters you pass in, and whether or not the method may
return null.

Basically, make sure you know at all times which of your variables may
be null, and what it means for them to be null. Then don't dereference
those null values :)
 
Hi Max,


Well I think that you will not find what you are looking for, now the
question to ask is why you are getting so much null values in your program,
are you sure you initialize all your variables correctly? are you checking
for null before using a object, it's non uncommon method returning null when
a value is not found like this example:

DataRow row = dataset.Tables["table1"].Rows.Find( pk );
//I have to check if row is a valid row or null
if ( row != null ) { .... }


Other than that, I do not what to advise you.

Hope this help,
 
Max Sandman said:
I'm getting increasingly frustrated with C# and its exceptions on null
values. Rather than try to deal with it on a hit-or-miss basis as
exceptions pop up, I thought I should try to learn exactly how C# deals
with null. Of course, there's nothing obvious in the docs like "Dealing
with Null Values" and a search on "null" yielded 500 results, most of
which don't apply. Can anybody point me in the right direction? Or offer
some general guidelines? Or even the correct keyword to search the docs?
Click to expand...

Hi Max,

Off the top of my head, here are a few coding practices that I use to avoid
these types of problems:

1. Initialize variables so you always know they are in a valid state. If
you explicitly initialize them to null, you know that they start off in an
invalid state (anticipating that the algorithm should bring them to a valid
state) and you should check them before you use them.

2. Check for null before making library calls to 3rd pary libraries where
null is invalid.

3. Use Debug.Assert for pre and post-condition checking to make sure your
algorithms start and end in valid states. It's really easy to use for
pre-conditions, i.e. making sure input parameters are not null.

4. Get NUnit, http://nunit.org/, (or another unit testing tool that you
would prefer) and test positive and negative conditions. I use this all the
time and do regular regression tests that keep me out of trouble.

Joe
 
Joe said:
3. Use Debug.Assert for pre and post-condition checking to make sure your
algorithms start and end in valid states. It's really easy to use for
pre-conditions, i.e. making sure input parameters are not null.
Click to expand...

I would suggest not using Debug.Assert for that kind of thing - I'd use
a straight exception:

if (someParameter==null)
throw new ArgumentNullException ("someParameter");

At least for non-private methods - it would make sense to use
assertions for private methods.
 
Jon Skeet said:
I would suggest not using Debug.Assert for that kind of thing - I'd use
a straight exception:

if (someParameter==null)
throw new ArgumentNullException ("someParameter");

At least for non-private methods - it would make sense to use
assertions for private methods.
Click to expand...

Actually, I do both. Maybe I'm afraid someone else on the team will eat the
exception and I want to make sure they don't overlook it. :)

Joe
 
I'm finding null to be a bit frustrating too. What am I missing?

Consider the following example...

object o = null;

System.String x = null;

o = null;

y y1=null;

if(o!=null)

{

Console.WriteLine(o.ToString());

}





y is defined as follows:

class y

{

}



My frustration is that o is *never* null. I watch it in the debugger and
even the assignment makes it not null. Why?

System.String starts and null and happily stays that way.

What is going on?
 
I'm finding null to be a bit frustrating too. What am I missing?

Consider the following example...

object o = null;
System.String x = null;
o = null;
y y1=null;
if(o!=null)
{
Console.WriteLine(o.ToString());
}

y is defined as follows:

class y
{
}

My frustration is that o is *never* null. I watch it in the debugger and
even the assignment makes it not null. Why?
Click to expand...

I'm sure it's just the debugger being strange - o certainly *is* null.
Here's a program to demonstrate that, using bits of your code:

using System;

public class Test
{
static void Main()
{
object o = null;

System.String x = null;

o = null;

if(o!=null)
{
Console.WriteLine(o.ToString());
}
else
{
Console.WriteLine ("o was null");
}
}
}
 
Hi Abel,

In my machine it shows the three as null , both in the watch window and the
quickwatch.

Cheers,
 
Agreed. I guess one of the really strange things for me is that the
System.String x (see example) is indeed shown as null in the debugger. The
two other objects -- object and a reference to a dirty little class I wrote,
are <undefined value>

It seems inconsistant.
 
Back
Top