Yet Another "Use of unassigned local variable 'whatever' " question

This is something that I have wondered about for a while now. I have browsed a bunch of questions containing the error below in their title but couldn't find one开发者_C百科 that explains this case.

First look at this example:

private void test() {
    string errorMessage;
    bool isOK = SomeClassWithBusinessRules.VerifySomeStuff(idOfStuffToVerify, ref errorMessage);
    if (!isOK)
        throw new BusinessException(errorMessage ?? "Some error occured.");
}

If you compile this the compiler will complain with this message:

Error 2 Use of unassigned local variable 'errorMessage'

Changing the variable initializer to null will make it go away.

This will compile:

private void test() {
    string errorMessage = null;
    bool isOK = SomeClassWithBusinessRules.VerifySomeStuff(idOfStuffToVerify, ref errorMessage);
    if (!isOK)
        throw new BusinessException(errorMessage ?? "Some error occured.");
}

So why do we get the compilation error?

When you pass it to VerifySomeStuff, you are specifying ref but it does not yet have a value. That is not legal, as VerifySomeStuff could choose to read the value, which does not have a defined value at this point. Assigning null satisfies the definite assignment requirement. An alternative would be out:

string errorMessage;
bool isOK = SomeClassWithBusinessRules.VerifySomeStuff(id, out errorMessage);
if (!isOK)
    throw new BusinessException(errorMessage ?? "Some error occured.");

which would be legal (but requires changes to VerifySomeStuff, since the signature must be changed and it is now required to assign a value to the parameter before exit (unless an exception occurs)). From the code shown, it you might choose for VerifySomeStuff to assign null to the parameter if there is no error.

Of course, if the bool and string then duplicate the "was there a problem" purpose, you could also use:

string errorMessage = SomeClassWithBusinessRules.VerifySomeStuff(id);
bool isOK = errorMessage == null;

You get the compilation error because a variable used as a ref argument has to be definitely assigned beforehand. If you change the method to use an out parameter instead, it'll be fine:

bool isOK = SomeClass.VerifySomeStuff(id, out errorMessage);

Note that this requires a change to VerifySomeStuff too, to make it an out parameter. The method would then have to definitely assign a value in any "normal" return path - so that by the time the method returns normally, errorMessage is definitely assigned.

See sections 10.6.1.2 and 10.6.1.3 details of ref and out parameters respectively.

You are passing errorMessage by ref. This has in/out semantics. In other words, the protocol is that recipient can expect the object to have been initialised, which you did not do.

It seems as though you simply want out semantics. Change VerifySomeStuff to use out rather than ref for errorMessage, and also change the calling code to use out.

Note that when you pass using out, the callee is not allowed to read until the object has been initialized. The callee also has the responsibility of performing that inialization before returning.

You can also correct the 'error' by changing the method to

 SomeClassWithBusinessRules.VerifySomeStuff(int idOfStuffToVerify, 
            out string  errorMessage);

When you use out the burden shifts to the method, it will not compile unless you make an assignment to the errorMessage parameter.

When passing a ref argument, one of the things the called code can do is re-point the ref argument variable to a new location i.e. update its reference. In order for this to happen, the variable must point to something in the first place, therefore it must be assigned, even if this is just to null.

Your question (why does the compiler complain) has already been answered by others. I would, however, suggest that you reconsider your design:

bool isOK = SomeClassWithBusinessRules.VerifySomeStuff(idOfStuffToVerify, ref errorMessage);
if (!isOK)
    throw new BusinessException(errorMessage ?? "Some error occured.");
}

Since errorMessage is only needed when an error occurs, why do you need the extra return value? You could shorten this to:

string error = SomeClassWithBusinessRules.VerifySomeStuff(idOfStuffToVerify);
if (error != null)
    throw new BusinessException(error);
}

(Of course, then you don't have the "Some error occured" case anymore. But showing "useless" error messages is bad practice anyway.)

In fact, if the error is an exceptional circumstance (i.e., something that's not part of the regular control flow but rather something indicating a data or logic error), it might make sense to move the exception inside VerifySomeStuff:

// no return value
SomeClassWithBusinessRules.VerifySomeStuff(idOfStuffToVerify);

class SomeClassWithBusinessRules {
    void VerifySomeStuff(int id) {
        ...
        if (someCondition)
            throw new BusinessException(error);
        ...
    }
}