Why C# local variable should be assigned directly, even if it's default value?

Question

If you look at next example:

public void TestLocalValuesAssignment()
{
    int valueVariable; // = default(int) suits fine
    string refType; // null suits fine as well

    try
    {
        valueVariable = 5;
        refType = "test";
    }
    catch (Exception){}

    Console.WriteLine("int value is {0}", valueVariable);
    Console.WriteLine("String is {0}", refType);
}

you could easily see, that variables valueVariable and refType could be unassigned before their usage in Console.WriteLine(). Compiler tells us about that with errors:

Error   1   Use of unassigned local variable 'valueVariable'
Error   2   Use of unassigned local variable 'refType'  

This is a widespread case and there are loads of answers on how to fix that (possible fixes commented).

What I can't understand is why such behavior exists? How here local variables are different from class fields, where last ones get default value if not assigned (null for reference types and correspondent default value for value types)? Maybe there's an example or a corner case that explains why such compiler behavior is chosen?

Answer 1

basically - this is what MS decided.

If you want more you can read here and check Eric Lippert’s Blog

The reason this is illegal in C# is because using an unassigned local has high likelihood of being a bug.

Answer 2

It's described in c# spec:

5.1.7 Local variables

A local variable introduced by a local-variable-declaration is not automatically initialized and thus has no default value. For the purpose of definite assignment checking, a local variable introduced by a local-variable-declaration is considered initially unassigned. A local-variable-declaration may include a local-variable-initializer, in which case the variable is considered definitely assigned only after the initializing expression (§5.3.3.4).

Within the scope of a local variable introduced by a local-variable-declaration, it is a compile-time error to refer to that local variable in a textual position that precedes its local-variable-declarator. If the local variable declaration is implicit (§8.5.1), it is also an error to refer to the variable within its local-variable-declarator.

Answer 3

When you do something that appears stupid, like reading from a variable you've never assigned, there are basically two things the compiler can do:

1. Give you a diagnostic calling your attention to what likely is a mistake.
2. Do something arbitrary.

Since option #1 helps you find mistakes, it is preferred, especially when the workaround to tell the compiler "No, I mean to use the original default value" is as simple as adding = 0, = null or = default(T).

As for why class members don't work the same way, it's because this can't be checked at compile time (because of the myriad different orders that the different methods could be called). There would be runtime cost of flags whether each member had been assigned, and testing of those flags.

Note that the compiler does enforce the restriction on struct members in a way that's easy to check at compile-time. Namely, each constructor is required to assign every member.

Answer 4

In reality, your code should be fine, but by strict interpretation, there is a code path which can leave your variables unassigned before use. The try block introduces the potential for code within the block to not be executed (if an exception is thrown), but still execute the code beyond the catch (because there is nothing in the catch such as return or throw to prevent the rest of your method from executing if an exception is thrown in the try).

If you are referring to the difference between initializing "struct" fields and initializing class fields, eg:

public class A
   {
   }

       MyMethod()
       {
           int myInt; // Initialized to zero, yes, but not yet assigned.
                      // An error to use this before assigning it.

           A myA;  // defaults to null, which may be a valid initial state, but still unassigned.
                   // Also an error to use this before assigning it.

           A oneMoreA = null; // Same value as default, but at least intention is clear.
           A anotherA = new A(); // What is or is not happening in the constructor is a separate issue.
                                 // At least anotherA  refers to an actual instance of the class.