I'm getting an unexpected NullReferenceException
when I run this code, omitting the fileSystemHelper
parameter (and therefore defaulting it to null):
public class GitLog
{
FileSystemHelper fileSystem;
/// <summary>
/// Initializes a new instance of the <see cref="GitLog" /> class.
/// </summary>
/// <param name="pathToWorkingCopy">The path to a Git working copy.</param>
/// <param name="fileSystemHelper">A helper class that provides file system services (optional).</param>
/// <exception cref="ArgumentException">Thrown if the path is invalid.</exception>
/// <exception cref="InvalidOperationException">Thrown if there is no Git repository at the specified path.</exception>
public GitLog(string pathToWorkingCopy, FileSystemHelper fileSystemHelper = null)
{
this.fileSystem = fileSystemHelper ?? new FileSystemHelper();
string fullPath = fileSystem.GetFullPath(pathToWorkingCopy); // ArgumentException if path invalid.
if (!fileSystem.DirectoryExists(fullPath))
throw new ArgumentException("The specified working copy directory does not exist.");
GitWorkingCopyPath = pathToWorkingCopy;
string git = fileSystem.PathCombine(fullPath, ".git");
if (!fileSystem.DirectoryExists(git))
{
throw new InvalidOperationException(
"There does not appear to be a Git repository at the specified location.");
}
}
When I single step the code in the debugger, after I step over the first line (with the ??
operator) then fileSystem
still has the value null, as shown in this screen snip (stepping over the next line throws NullReferenceException
):
This is not what I expected! I'm expecting the null coalescing operator to spot that the parameter is null and create a new FileSystemHelper()
. I have stared at this code for ages and can't see what is wrong with it.
ReSharper pointed out that the field is only used in this one method, so could potentially be converted to a local variable… so I tried that and guess what? It worked. So, I have my fix, but I cannot for the life of me see why the code above doesn't work. I feel like I am on the edge of learning something interesting about C#, either that or I've done something really dumb. Can anyone see what's happening here?
Best Answer
I have reproduced it in VS2012 with the following code:
If you set a breakpoint at the end of the
TestFoo
method, you would expect to see the_foo
variable set, but it will still show as null in the debugger.But if you then do anything with
_foo
, it then appears correctly. Even a simple assignment such asIf you step through it, you'll see that
_foo
shows null until it is assigned tof
.This reminds me of deferred execution behavior, such as with LINQ, but I can't find anything that would confirm that.
It's entirely possible that this is just a quirk of the debugger. Perhaps someone with MSIL skills can shed some light on what is happening under the hood.
Also interesting is that if you replace the null coalescing operator with it's equivalent:
Then it does not exhibit this behavior.
I am not an assembly/MSIL guy, but just taking a look at the dissasembly output between the two versions is interesting:
Compare that to the inlined-if version:
Based on this, I do think there is some kind of deferred execution happening. The assignment statement in the second example is very small in comparison to the first example.