newbie question: null

  • Thread starter Thread starter rno
  • Start date Start date
R

rno

Hi,

Pls bear with me as I am very new to C#. Would appreciate some insite
on this:

I have a string[][] A

I have a method that goes something like this

string[][] bla()

string[][] x = null;
{
try
{
...some code..
}
catch
{
...a COM exception..
}
return x;
}

The idea being that I can check for null if an exception occurred,
the exception itself is expected and I want to ignore it. (this is all
in some loop)

When I do A = bla();

and check for A with if (A != null), the code following will still
run, even if (or so the debugger tells me), A is null.

When I hover over the A in A != null , VS tells me A is null, and when
I hover over the != part it tells me that null != null equals false.
Eh, that makes sense too? What am I missing? How do I check for 'A is
not null'?

Clearly, I must be missing something fundamental here, but what?

tia
arno
 
I have a string[][] A

I have a method that goes something like this

string[][] bla()

string[][] x = null;
{
try
{
..some code..
}
catch
{
..a COM exception..
}
return x;
}

The idea being that I can check for null if an exception occurred,
the exception itself is expected and I want to ignore it. (this is all
in some loop)
Click to expand...

That does not sound as a good design.
When I do A = bla();

and check for A with if (A != null), the code following will still
run, even if (or so the debugger tells me), A is null.

When I hover over the A in A != null , VS tells me A is null, and when
I hover over the != part it tells me that null != null equals false.
Eh, that makes sense too? What am I missing? How do I check for 'A is
not null'?
Click to expand...

Could you post the actual code?

Arne
 
Hi,

Pls bear with me as I am very new to C#. Would appreciate some insite
on this:

I have a string[][] A

I have a method that goes something like this

string[][] bla()

string[][] x = null;
{
try
{
..some code..
}
catch
{
..a COM exception..
}
return x;
}

The idea being that I can check for null if an exception occurred,
the exception itself is expected and I want to ignore it. (this is all
in some loop)

When I do A = bla();

and check for A with if (A != null), the code following will still
run, even if (or so the debugger tells me), A is null.

When I hover over the A in A != null , VS tells me A is null, and when
I hover over the != part it tells me that null != null equals false.
Eh, that makes sense too? What am I missing? How do I check for 'A is
not null'?

Clearly, I must be missing something fundamental here, but what?

tia
arno
Click to expand...

Exceptions are for Exceptional things, not normal operations. There has
got to be a abetter way...

Regardless, the following code does not behave as you say, so there is
something in your code that you are missing. This code produces
"null..." for me.

class Program
{
string [] [] Blah()
{
string[][] x = null;
try
{
// some code....
}
catch
{
// ..a COM exception..
}
return x;
}

static void Main(string[] args)
{
Program p = new Program();
string [] [] a = p.Blah();
if (a != null) Console.WriteLine("not null...");
else Console.WriteLine("null...");
Console.ReadKey();
}
}
 
@Mike: ok, will look again. However, how would you explain that as I
hover over my variables when the NullReferenceException occurs, my A
is said to be null, yet 'if (A != null)' continues to run?

@Arne: not sure if posting the actual code is useful, but here is the
general idea:

in my method bla, that gets called for a preset number of values z:

string[][] bla(int z)
string[][] x = null;
{
try
{
ISomeType x = someLegacyProggie.GetCursor(int someConduitID)
/* This will fail with a COMException if no user preferences were made
for the conduit in someLegacyProggie. That is to be expected, and
there is nothing I can do about it; I simply know that in that case
there are no settings to be read for that someConduitID, and I just
want to exit
*/
...manipulate x...
}
{
...catch the COMException
}
return x
}

I suppose that can be bad design, but I do not quite see how to do it
in a better way. Would very much appreciate suggestions.

tia
arno

Hi,

Pls bear with me as I am very new to C#. Would appreciate some insite
on this:

I have a string[][] A

I have a method that goes something like this

string[][] bla()

string[][] x = null;
{
try
{
..some code..
}
catch
{
..a COM exception..
}
return x;
}

The idea being that I can check for null if an exception occurred,
the exception itself is expected and I want to ignore it. (this is all
in some loop)

When I do A = bla();

and check for A with if (A != null), the code following will still
run, even if (or so the debugger tells me), A is null.

When I hover over the A in A != null , VS tells me A is null, and when
I hover over the != part it tells me that null != null equals false.
Eh, that makes sense too? What am I missing? How do I check for 'A is
not null'?

Clearly, I must be missing something fundamental here, but what?

tia
arno
Click to expand...

Exceptions are for Exceptional things, not normal operations. There has
got to be a abetter way...

Regardless, the following code does not behave as you say, so there is
something in your code that you are missing. This code produces
"null..." for me.

class Program
{
string [] [] Blah()
{
string[][] x = null;
try
{
// some code....
}
catch
{
// ..a COM exception..
}
return x;
}

static void Main(string[] args)
{
Program p = new Program();
string [] [] a = p.Blah();
if (a != null) Console.WriteLine("not null...");
else Console.WriteLine("null...");
Console.ReadKey();
}
}
Click to expand...
 
rno said:
@Mike: ok, will look again. However, how would you explain that as I
hover over my variables when the NullReferenceException occurs, my A
is said to be null, yet 'if (A != null)' continues to run?

@Arne: not sure if posting the actual code is useful, but here is the
general idea:

in my method bla, that gets called for a preset number of values z:

string[][] bla(int z)
string[][] x = null;
Click to expand...

The above isn't valid code, so this can't be how your method works.
 
On 2/20/2010 6:16 PM, rno wrote:
Click to expand...
Regardless, the following code does not behave as you say, so there is
Click to expand...


Whuaa I am terribly sorry to have bothered you with this; it would seem
that removing some code that accidentally was outside my { } resolved
the problem. Again, sorry for wasting your time.

arno
 
Whuaa I am terribly sorry to have bothered you with this; it would seem
that removing some code that accidentally was outside my { } resolved
the problem. Again, sorry for wasting your time.

arno
Click to expand...

No bother at all. We all learned this same way, by making mistakes.
It's also been learned that usually the "missing piece" of code is where
the problem is.
 
Back
Top