Why doesn't my C# compiler (Visual Studio) let me do this with a try block?

Question

I have many scenarios during my development where I want to do something such as

try 
{ 
    long presult = EvalInner(eqtn,new Tuple<int, int>(++begidx,curidx-1),eqtnArgs); 
}
catch ( Exception e ) 
{ 
    throw e; 
}
result = evalNewResult(result,lastop,presult,ref negateNextNum,ref negateNextOp); 
// ...
return presult;

but then my compiler flags the presult on the line

result = evalNewResult(result,lastop,presult,ref negateNextNum,ref negateNextOp); 

saying

The name 'presult' does not exist in the current context

If it were smart, it would understand that presult is either initialized in the try block, or the procedure is exited before presult is ever used.

Possible workarounds (none of them good):

1. Declare long presult; right before the try statement. This makes the compiler mad because it wrongly thinks there's a possibility of returning an unintialized variable.
2. Initialize it with long presult = default(long). This works, but it's bad practice because someone reading the code doesn't know whether intializing it to the default value is to work around the problem described in 1. or is because the value presult because set to the default long has some real meaning in the context of the program.
3. Initialize it with long? presult = null. This is semantically better because it's clear that it means "presult is meant to have no value at this point" whereas in 2. the reader has to figure out that presult has a meaningless value. The problem here is that, not only does it take extra memory to nullify a value, but I then have to change the function EvalInner to return a long? and this results in a chain of needing to change many more longs to long?s and my program ends up splattered with nullified variables; it's a complete mess of question marks haha.

Anyways, how should I be handling a case like this?

Answer 1

I'll go over your points one by one:

1. Declare long presult; right before the try statement. This makes the compiler mad because it wrongly thinks there's a possibility of returning an unintialized variable.

Actually, the compiler correctly determines that there is the possibility of returning an uninitialized variable. Since the variable is only set if the function on the right hand side succeeds, and since you have it in a try..catch block then there is the possibility that the function may throw and not return, therefore not initializing the variable. What the compiler is not smart enough to see is that you are catching the top level exception and throwing (in a bad way, losing the stack trace) and it should not reach the return. However there are ways to get around that (mostly during debug by dragging the execution cursor).

2. Initialize it with long presult = default(long). This works, but it's bad practice because someone reading the code doesn't know whether intializing it to the default value is to work around the problem described in 1. or is because the value presult because set to the default long has some real meaning in the context of the program.

Since value types like long, int, short etc must have a value, this is not bad practice. If you want to represent them as not having a value, use the nullable versions of those types (i.e. long? presult = null).

3. Initialize it with long? presult = null. This is semantically better because it's clear that it means "presult is meant to have no value at this point" whereas in 2. the reader has to figure out that presult has a meaningless value. The problem here is that, not only does it take extra memory to nullify a value, but I then have to change the function EvalInner to return a long? and this results in a chain of needing to change many more longs to long?s and my program ends up splattered with nullified variables; it's a complete mess of question marks haha.

Again, the function must return a value that is a valid long, so if you want to return something that can easily be identified as an incorrect value, then return the nullable version, otherwise you have to return a valid value. Only float and double have NaN members...

Another option would be some kind of TryXXX method, where the return value is a boolean and you use an out long as a parameter to store the result.

Answer 2

How about:

try 
{ 
    long presult = EvalInner(eqtn,new Tuple<int, int>(++begidx,curidx-1),eqtnArgs); 
    result = evalNewResult(result,lastop,presult,ref negateNextNum,ref negateNextOp); 
    // ...
    return presult;
}
catch ( Exception e ) 
{ 
    //Do some useful logging
    throw; //Don't lose stacktrace!
}

Answer 3

I don't understand you problem. The compiler can't know the value of presult when you call evalNewResult that's why you need to declare it outside the try block. It's a general rule of scopes in C# and a lot of other languages.

The solution is to declare and initialize it before the try block. The question is "what value should presult have in case an exception occurs". The compiler can't ask this question himslef.

Answer 4

Please check this link for more enlightment

Compilers are in the business of generating code which manages the storage of the data manipulated by that program. There are lots of different ways of generating code to manage memory, but over time two basic techniques have become entrenched.

The first is to have some sort of "long lived" storage area where the "lifetime" of each byte in the storage -- that is, the period of time when it is validly associated with some program variable -- cannot be easily predicted ahead of time. The compiler generates calls into a "heap manager" that knows how to dynamically allocate storage when it is needed and reclaim it when it is no longer needed.

The second is to have some sort of "short lived" storage area where the lifetime of each byte in the storage is well known, and, in particular, lifetimes of storages follow a "nesting" pattern. That is, the allocation of the longest-lived of the short-lived variables strictly overlaps the allocations of shorter-lived variables that come after it.

Local variables follow the latter pattern; when a method is entered, its local variables come alive. When that method calls another method, the new method's local variables come alive. They'll be dead before the first method's local variables are dead. The relative order of the beginnings and endings of lifetimes of storages associated with local variables can be worked out ahead of time.

For this reason, local variables are usually generated as storage on a "stack" data structure, because a stack has the property that the first thing pushed on it is going to be the last thing popped off.

So overall local variable are are short lived and usually stored in stack, why stack coz its efficient than others. Link for more info why stack

Answer 5

Why doesn't my C# compiler (Visual Studio) let me do this with a try block?

That is because braces define a scope. From Variable and Method Scope in Microsoft .NET:

If you declare a variable within a block construct such as an If statement, that variable's scope is only until the end of the block. The lifetime is until the procedure ends.

how should I be handling a case like this?

Go for option 1.

This makes the compiler mad because it wrongly thinks there's a possibility of returning an unintialized variable

Option 1 does not make the compiler mad. The compiler is always right :-)

I created the following SSCCE and it absolutely works:

using System;

namespace app1
{
    class Program
    {
        static void Main(string[] args)
        {
            Presult();
        }

        private static long Presult()
        {
            long presult;
            try
            {
                object eqtn = null;
                char begidx = '\0';
                int curidx = 0;
                object eqtnArgs = null;
                presult = EvalInner(eqtn, new Tuple<int, int>(++begidx, curidx - 1), eqtnArgs);
            }
            catch (Exception e)
            {
                throw e;
            }
            int result = 0;
            object lastop = null;
            object negateNextNum = null;
            object negateNextOp = null;
            result = evalNewResult(result, lastop, presult, ref negateNextNum, ref negateNextOp);
            // ...
            return presult;
        }

        private static int evalNewResult(int result, object lastop, long presult, ref object negateNextNum, ref object negateNextOp)
        {
            return 0;
        }

        private static long EvalInner(object eqtn, Tuple<int, int> tuple, object eqtnArgs)
        {
            return 0;
        }
    }
}

Answer 6

how should I be handling a case like this?

The correct way is your Option 1. That doesn't make compiler "mad", because in fact declaring a variable and initializing it later is allowed construct (not only for this particular case) from the very beginning, and compiler should be able to handle it correctly w/o problem.

IMO, the only drawback (or better say inconvenience) is that the keyword var cannot be used, so the type must be specified explicitly. But some people that are against using var in general would say this is indeed a good thing :-)