cs0165 - the error that keeps on giving

[ritterhaus]

I'm an unashamed C coder learning C#, and in my first 24 hours with
the language I've already found my first TIDL (thing I don't like),
the inane "error cs0165." I'm sure that this has been discussed and
argued over at great length, but I'm having trouble finding useful
information about why this is considered to be an error and not a
warning. The compiler is often not bright enough to account for the
application logic (flow analysis my eye) and I find that perfectly
valid, error-free pieces of code refuse to compile because C# thinks
I'm too stupid to assign to a local variable before I use it.

The fact is, in my very first C# program (rewriting one of the C
examples I teach with in class) I get this error in two places: both
times the code is perfectly good and the variables hold proper values,
but csc doesn't seem to think so. If this would compile with merely a
warning I could live with that, because unassigned variables are a
Very Bad Thing, but to stop the compile for spurious problems based on
faulty flow analysis seems to me to be overkill.

Is there any intelligent reason for this design, or any intent to
change it in the future? I don't like stray pointers any more than the
next guy, but by gum, when I assign to my variables I don't expect to
be told that they are "unassigned" by some lazy compiler that won't do
as its been told.

RR

 

[Robert]

You didn't post a code sample to illustrate what you think is an erroneous
report of this error. However, I'll make the assumption that you've got
some code that you know for sure will get through at least one path that
will initialize a variable, but the compiler isn't noticing it.

True. I said I had two instances of this error borrowed from an old C
program. Here they are:

int input;
System.Console.Write("\nEnter a number: ");
while (true){
try{
input = int.Parse(System.Console.ReadLine());
break;
} catch {}
}
if (input > 0 && input < 10) System.Console.WriteLine("\nYou entered
{0}\n\n.", input);

Now, I don't want input to be initialized to zero; in fact, I want it
to have no value at all unless explicitly assigned by the user, so
input can ONLY be zero if the user entered zero. Initializing the int
to a default value makes no sense in the program's logic. And note
that the statement that accesses the variable is "unreachable" until
input is assigned, so this is NOT an unassigned variable.

Also:

string verb;
int year = 2000, thisYear = 2008;
// get proper verb tense
if (year < thisYear) verb = "was";
if (year == thisYear) verb = "is";
if (year > thisYear) verb = "will be";
System.Console.WriteLine("\nThat {0} a very good year.\n\n", verb);

In this instance verb MUST be assigned because the three if statements
account for all possible values of year. When the WriteLine is called,
verb will always be assigned.

I reported this as a bug long ago, was told it's "by design". The C#
specification has a lengthy description of the exact definition of
"definitely assigned" and variables that are used at some point before
they have become "definitely assigned" cause this error to be emitted.

So perhaps I disagree with the standard's definition of "definitely
assigned." I can buy that, as I tend to be pretty opinionated and
stubborn (after all, I'm still using C, right?)

For me, the inconvenience of having to assign variables isn't such a big
deal. My concern is that I think it's a very good idea for the compiler
to treat unassigned variables as a bug, but forcing the programmer to
assign variables to some default value that should never actually be used
winds up with the potential for obscuring an actual "unassigned variable"
bug.

I think that that is my point exactly. In my source code, initialized
variables imply some default value that may (or must) be used in
absence of any other value. This same program uses:

bool nan = true;

because my intent is for all user input to be treated as NAN until
some condition exists to explicitly change that. In this case, it
makes sense to initialize the variable. I suppose my beef is that I am
being forced by the compiler to make my code LESS clear (to me,
anyway) so that it can be MORE SURE that I didn't do something
brainless. Which takes me back to the original thought of a compiler
warning. Yes, I've written my share of bugs because I didn't
initialize a variable, but it was never THAT big of a deal: a quick
run or two through the debugger and it becomes pretty obvious. If the
compiler flagged these instances as a POSSIBLE problem I could check
them out, determine that they are fine, and move on. The fact that the
compiler refuses to compile working code disturbs me more than a
little.

But I also can see the value in keeping the rules for definite assignment
simple, and not requiring the compiler to do logical analysis of the
code. I can't say I'm 100% happy about the current implementation, but I
also wouldn't go ranting about it either. It's not really an issue worth
getting your shorts in a twist over, though a nice calm discussion could
be fine.

Agreed, and a compiler warning would be great. I for one actually read
all those warnings messages. Just my two cents.

RR