We Keep Coding

Use of unassigned local variable Abstract classes [duplicate]

On MSDN, this code is posted at https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch I am unable to understand why it throws the error:
Use of unassigned local variable 'n'.
static void Main()
{
int n;
try
{
// Do not initialize this variable here.
n = 123;
}
catch
{
}
// Error: Use of unassigned local variable 'n'.
Console.Write(n);
}

Compiler Error CS0165
The C# compiler does not allow the use of uninitialized variables. If
the compiler detects the use of a variable that might not have been
initialized, it generates compiler error CS0165. For more information,
see Fields. Note that this error is generated when the compiler
encounters a construct that might result in the use of an unassigned
variable, even if your particular code does not. This avoids the
necessity of overly-complex rules for definite assignment.
More-so, imagine this situation
int n;
try
{
throw new Exception();
n = 123; // this code is never reached
}
catch
{
}
// oh noez!!! bam!
// The compiler is trying to be nice to you
if(n == 234);
In short, computer says no
Note : when you get a compiler error in visual studio, you can click on the error code and it sometimes (if you are lucky) gives you more concise information about what the error means

I believe, what you're confused about, is that even though the variable n appears to be initialized, why the compiler complains it isn't?
And there's a good reason for that; even though n is initialized at one point, it isn't initialized in all possible paths. In other words, you have to account for each scenario in your code and ensure that in all of them, the initialization occurs.
But in this case, it doesn't satisfy that condition. In your try block, if there was an exception before the program gets to execute the n = 123; line, the program will go to the catch and then following that, will go to your Console.Write(n) line at which point you're trying to print a variable that isn't initialized.
So, the best way to prevent such a scenario is to initialize the variable before the try block. In general it is advised that you always initialize a variable as soon as it is declared.
EDIT
From a beginner's point of view, you might argue that there's only one line of code inside the try block, and therefore there's no way the program will not execute the initialization. But you must look at it from the compiler's perspective; it doesn't understand the intention of your program, it simply verifies (that's what a compiler does) if a program is written according to a predefined set of rules. And in this case, it isn't.

If you look at the article, you'll see the answer:
// Error: Use of unassigned local variable 'n'.
When you write int n; you do not initialize variable and try to use it in Console.Write(n);, so you will get compilation error: https://ideone.com/q3LXwl

This error is because you are using n in Console.Write() function. And suppose if Try block generates an exception then n would not be initialized. Therefore this error occurs.

What does happen when you make a struct without using the new keyword?

What does happen behind the scenes when you make a struct without using the new keyword?
Let's say we have this struct:
struct Person
{
public int Age;
public string Name;
}
And In the Main() method I decide to make an instance of it without the new keyword like that:
Person p;
now if I try to access p.Age I will get a compile-time error saying "Use of possibly unassigned field 'Age'" however if I make an instance of the struct like that:
Person p = new Person();
and then I try to access p.Age I will get the value of 0. Now what exactly happens behind the scenes? Does the Runtime initialize these variables for me or the compiler places code that initializes them in the IL after compilation?
Edit:
Can anybody also explain this behavior:
Code:
struct Person
{
public string Name { get; set; }
}
If I make instance of struct like that:
Person p;
and I initialize the name manually
p.Name = "SomeRandomName"';
I won't be able to use it. The compiler gives an error "Use of an unassigned local variable p" but If I make instance of the struct with the default (parameterless) constructor there isn't such an error.

Members don't have the same rules as locals.
Locals must be explicitly initialised before use. Members are initialised by the runtime to their respective default values.
If you want some more relevant information:
In the internal implementation details (non-contractual!), up to the current MS .NET runtime for Windows objects are allocated in pre-zeroed memory on the heap (when they're on the heap at all, of course). All the default values are "physical" zeroes, so all you need is e.g. "200 consecutive bytes with value 0". In many cases, this is as simple as asking the OS for a pre-zeroed memory page. It's a performance compromise to keep memory safety - you can easily allocate an array of 2000 Person instances by just doing new Person[2000], which just requests 2000 * size of Person bytes with value zero; extremely cheap, while still keeping safe default values. No need to initialise 2000 Person instances, and 2000 int instances and 2000 string instances - they're all zero by default. At the same time, there's no chance you'd get a random value for the string reference that would point to some random place in memory (a very common error in unmanaged code).
The main reason for requiring explicit initialisation of locals is that it prevents stupid programming errors. You should never access an uninitialised value in the first place, and if you need a default value, you should be explicit about it - the default value then gets a meaning, and meanings should be explicit. You'll find that cases where you could use an uninitialised local meaningfully in the first place are pretty rare - you usually either declare the local right where it gets a value, or you need all possible branches to update a pre-declared local anyway. Both make it easier to understand code and avoid silly mistakes.

If you go through the small struct documentation, you can quote:
A struct type is a value type that is typically used to encapsulate small groups of related variables, such as the coordinates of a rectangle or the characteristics of an item in an inventory.
Normally, when you declare in your code these value type like:
int i; // By default it's equal to 0
bool b; // by default it's equal to false.
Or a reference type as:
string s; //By default it's null
The struct you have created is a value type, which by default isn't initialized and you can't access its properties. Therefore, you can't declare it as:
Person p;
Then use it directly.
Hence the error you got:
"Use of possibly unassigned field 'Age'"
Because p is still not initialized.
This also explains your second part of the question:
I won't be able to use it. The compiler gives an error "Use of an unassigned local variable p" but If I make instance of the struct with the default (parameterless) constructor there isn't such an error.
The same reason you couldn't directly assign p.Name = "something" is because p is still not initialized.
You must create a new instance of the struct as
Person p = New Person(); //or Person p = default(Person);
Now, what happens when you create a new instance of your struct without giving values to the struct properties? Each one of them will hold it's default value. Such as the Age = 0 because it's an int type.

Every datatype in .NET has a default value. For all reference types it's null. For the special type string it is also null. For all value types it is something akin to zero. For bool it's false because this is the equivalent to zero.
You can observe the same behaviour when you write a class with member fields. After construction all these fields will have a default value even when none was assigned during construction.
The same is also true when you use a struct as a member. Since a struct cannot be null, it will also be initialized and all its members (again) use their default values.
The difference in compiler output is that the compiler cannot determine if you have initialized the member field through any means. But it can determine if you have set the method variable value before reading it. Technically this wouldn't be necessary but since it reduces programming errors (why would you read a variable you have not written?), the compiler error appears.

Confusion about value capturing in C# lambda

To illustrate my confusion, see the following example:
int a = 0;
Action act = () => ++a;
act();
Console.WriteLine(a);
I have difficulty figuring out how modification to the captured variable within the lambda could possibly affect the local variable a. First of all, the implicitly generated lambda function object could not store a reference to the local variable a. Otherwise, if act is returned and invoked later, the referenced local variable a would already be vanished. A solution to this problem would be copy-by-value, either by copying the int value directly or through boxing, so that the function object would have its own copy the local variable a. But this doesn't explain the example just given. So, what is the underlying mechanism? Would it be that the seemingly local variable a is actually no longer a local variable, but translated by the compiler to be a reference to an int field within the generated lambda function object?

The point here is closure. After compilation a is not a local variable anymore - it's a field of auto-generated class, both in function scope and in lambda.

Why are non-initialized value types not allowed? [duplicate]

I'm familiar with the C# specification, section 5.3 which says that a variable has to be assigned before use.
In C and unmanaged C++ this makes sense as the stack isn't cleared and the memory location used for a pointer could be anywhere (leading to a hard-to-track-down bug).
But I am under the impression that there are not truly "unassigned" values allowed by the runtime. In particular that a reference type that is not initialized will always have a null value, never the value left over from a previous invocation of the method or random value.
Is this correct, or have I been mistakenly assuming that a check for null is sufficient all these years? Can you have truly unintialized variables in C#, or does the CLR take care of this and there's always some value set?

I am under the impression that there are not truly "unassigned" values allowed by the runtime. In particular that a reference type that is not initialized will always have a null value, never the value left over from a previous invocation of the method or random value. Is this correct?
I note that no one has actually answered your question yet.
The answer to the question you actually asked is "sorta".
As others have noted, some variables (array elements, fields, and so on) are classified as being automatically "initially assigned" to their default value (which is null for reference types, zero for numeric types, false for bools, and the natural recursion for user-defined structs).
Some variables are not classified as initially assigned; local variables in particular are not initially assigned. They must be classified by the compiler as "definitely assigned" at all points where their values are used.
Your question then is actually "is a local variable that is classified as not definitely assigned actually initially assigned the same way that a field would be?" And the answer to that question is yes, in practice, the runtime initially assigns all locals.
This has several nice properties. First, you can observe them in the debugger to be in their default state before their first assignment. Second, there is no chance that the garbage collector will be tricked into dereferencing a bad pointer just because there was garbage left on the stack that is now being treated as a managed reference. And so on.
The runtime is permitted to leave the initial state of locals as whatever garbage happened to be there if it can do so safely. But as an implementation detail, it does not ever choose to do so. It zeros out the memory for a local variable aggressively.
The reason then for the rule that locals must be definitely assigned before they are used is not to prevent you from observing the garbage uninitialized state of the local. That is already unobservable because the CLR aggressively clears locals to their default values, the same as it does for fields and array elements. The reason this is illegal in C# is because using an unassigned local has high likelihood of being a bug. We simply make it illegal, and then the compiler prevents you from ever having such a bug.

As far as I'm aware, every type has a designated default value.
As per this document, fields of classes are assigned the default value.
http://msdn.microsoft.com/en-us/library/aa645756(v=vs.71).aspx
This document says that the following always have default values assigned automatically.
Static variables.
Instance variables of class instances.
Instance variables of initially assigned struct variables.
Array elements.
Value parameters.
Reference parameters.
Variables declared in a catch clause or a foreach statement.
http://msdn.microsoft.com/en-us/library/aa691173(v=vs.71).aspx
More information on the actual default values here:
Default values of C# types (C# reference)

It depends on where the variable is declared. Variables declared within a class are automatically initialized using the default value.
object o;
void Method()
{
if (o == null)
{
// This will execute
}
}
Variables declared within a method are not initialized, but when the variable is first used the compiler checks to make sure that it was initialized, so the code will not compile.
void Method()
{
object o;
if (o == null) // Compile error on this line
{
}
}

In particular that a reference type that is not initialized will always have a null value
I think you are mixing up local variables and member variables. Section 5.3 talks specifically about local variables. Unlike member variables that do get defaulted, local variables never default to the null value or anything else: they simply must be assigned before they are first read. Section 5.3 explains the rules that the compiler uses to determine if a local variable has been assigned or not.

There are 3 ways that a variable can be assigned an initial value:
By default -- this happens (for example) if you declare a class variable without assigning an initial value, so the initial value gets default(type) where type is whatever type you declare the variable to be.
With an initializer -- this happens when you declare a variable with an initial value, as in int i = 12;
Any point before its value is retrieved -- this happens (for example) if you have a local variable with no initial value. The compiler ensures that you have no reachable code paths that will read the value of the variable before it is assigned.
At no point will the compiler allow you to read the value of a variable that hasn't been initialized, so you never have to worry about what would happen if you tried.

All primitive data types have default values, so there isn't any need to worry about them.
All reference types are initialized to null values, so if you leave your reference types uninitialized and then call some method or property on that null ref type, you would get a runtime exception which would need to be handled gracefully.
Again, all Nullable types need to be checked for null or default value if they are not initialized as follows:
int? num = null;
if (num.HasValue == true)
{
System.Console.WriteLine("num = " + num.Value);
}
else
{
System.Console.WriteLine("num = Null");
}
//y is set to zero
int y = num.GetValueOrDefault();
// num.Value throws an InvalidOperationException if num.HasValue is false
try
{
y = num.Value;
}
catch (System.InvalidOperationException e)
{
System.Console.WriteLine(e.Message);
}
But, you will not get any compile error if you leave all your variables uninitialized as the compiler won't complain. It's only the run-time you need to worry about.

Why can't a duplicate variable name be declared in a nested local scope?

Based on this recent question, I don't understand the answer provided. Seems like you should be able to do something like this, since their scopes do not overlap
static void Main()
{
{
int i;
}
int i;
}
This code fails to compile with the following error:
A local variable named 'i' cannot be declared in this scope because it would give a different meaning to 'i', which is already used in a 'child' scope to denote something else

I don't think any of the answers so far have quite got the crucial line from the spec.
From section 8.5.1:
The scope of a local variable declared in a local-variable-declaration is the block in which the declaration occurs. It is an error to refer to a local variable in a textual position that precedes the local-variable-declarator of the local variable. Within the scope of a local variable, it is a compile-time error to declare another local variable or constant with the same name.
(Emphasis mine.)
In other words, the scope for the "later" variable includes the part of the block before the declaration - i.e. it includes the "inner" block containing the "earlier" variable.
You can't refer to the later variable in a place earlier than its declaration - but it's still in scope.

"The scope of local or constant variable extends to the end of the current block. You cannot declare another local variable with the same name in the current block or in any nested blocks." C# 3.0 in a Nutshell, http://www.amazon.com/3-0-Nutshell-Desktop-Reference-OReilly/dp/0596527578/
"The local variable declaration space of a block includes any nested blocks. Thus, within a nested block it is not possible to declare a local variable with the same name as a local variable in an enclosing block." Variable Scopes, MSDN, http://msdn.microsoft.com/en-us/library/aa691107%28v=vs.71%29.aspx
On a side note, this is quite the opposite that of JavaScript and F# scoping rules.

From the C# language spec:
The local variable declaration space of a block includes any nested blocks. Thus, within a nested block it is not possible to declare a local variable with the same name as a local variable in an enclosing block.
Essentially, it's not allowed because, in C#, their scopes actually do overlap.
edit: Just to clarify, C#'s scope is resolved at the block level, not line-by-line. So while it's true that you cannot refer to a variable in code that comes before its declaration, it's also true that its scope extends all the way back to the beginning of the block.

This has been a rule in C# from the first version.
Allowing overlapping scopes would only lead to confusion (of the programmers, not the compiler).
So it has been forbidden on purpose.

For C#, ISO 23270 (Information technology — Programming
languages — C#), §10.3 (Declarations) says:
Each block, switch-block, for-statement, foreach-statement, or
using-statement creates a declaration space for local variables and
local constants called the local variable declaration space. Names are
introduced into this declaration space through local-variable-declarations
and local-constant declarations.
If a block is the body of an instance
constructor, method, or operator declaration, or a get or set accessor for
an indexer declaration, the parameters declared in such a declaration are
members of the block’s local variable declaration space.
If a block is the
body of a generic method, the type parameters declared in such a declaration
are members of the block’s local variable declaration space.
It is an error
for two members of a local variable declaration space to have the same name.
It is an error for a local variable declaration space and a nested local
variable declaration space to contain elements with the same name.
[Note: Thus, within a nested block it is not possible to declare a local
variable or constant with the same name as a local variable or constant
in an enclosing block. It is possible for two nested blocks to contain
elements with the same name as long as neither block contains the other.
end note]
So
public void foobar()
{
if ( foo() )
{
int i = 0 ;
...
}
if ( bar() )
{
int i = 0 ;
...
}
return ;
}
is legal, but
public void foobar()
{
int i = 0 ;
if ( foo() )
{
int i = 0 ;
...
}
...
return ;
}
is not legal. Personally, I find the restriction rather annoying. I can see issuing a compiler warning about scope overlap, but a compilation error? Too much belt-and-suspenders, IMHO. I could see the virtue of a compiler option and/or pragma , though ( perhaps -pedantic/-practical, #pragma pedantic vs #pragma practical, B^)).

It's not a question of overlapping scopes. In C# a simple name cannot mean more than one thing within a block where it's declared. In your example, the name i means two different things within the same outer block.
In other words, you should be able to move a variable declaration around to any place within the block where it was declared without causing scopes to overlap. Since changing your example to:
static void Main()
{
int i;
{
int i;
}
}
would cause the scopes of the different i variables to overlap, your example is illegal.

I just compiled this in GCC both as C and as C++. I received no error message so it appears to be valid syntax.
Your question is tagged as .net and as c. Should this be tagged as c#? That language might have different rules than C.

In C you need to put all variable declaration at the very beginning of a block. They need to come all directly after the opening { before any other statements in this block.
So what you can do to make it compile is this:
static void Main()
{
{
int i;
}
{
int i;
}
}

Here's your answer from MSDN .NET Documentation:
...The local variable declaration space of a block includes any nested blocks. Thus, within a nested block it is not possible to declare a local variable with the same name as a local variable in an enclosing block.