Question

I must be missing something… How can an exception be thrown, yet the code following the exception still gets hit in the debugger?

private UpdaterManifest GetUpdaterManifest()
{
    string filePathAndName = Path.Combine(this._sourceBinaryPath, this._appName + ".UpdaterManifest");

    if (!File.Exists(filePathAndName))
    {
        // This line of code gets executed:
        throw new FileNotFoundException("The updater manifest file was not found. This file is necessary for the program to run.", filePathAndName);
    }

    UpdaterManifest updaterManifest;

    using (FileStream fileStream = new FileStream(filePathAndName, FileMode.Open))
    {
        // ... so how is it that the debugger stops here and the call stack shows
        // this line of code as the current line? How can we throw an exception
        // above and still get here?
        XmlSerializer xmlSerializer = new XmlSerializer(typeof(UpdaterManifest));
        updaterManifest = xmlSerializer.Deserialize(fileStream) as UpdaterManifest;
    }

    return updaterManifest;
}

Answer 1

Some scenario’s where this can generally happen:

• when the option “Require source files to exactly match the original version” switched off. In that case, you don’t get a warning when your files are out of sync.

• when the IDE asks for “There were build errors. Would you like to continue and run the last successful build?”, in which case the IDE can be wrong about the correct line, because it runs an earlier version.

• when you are debugging a release version of your code, where certain parts are optimized away. This results in the highlighted line to be the next available line in the source that reflects and actual statement in the optimized code (this you’ll often see when debugging with external assemblies that are optimized).

---

EDIT: I kind-of misread your code. Between the “throw” and the line that gets highlighted, there’s only a declaration of a variable, no code at all to be executed. I assume that you meant that the code “using…” was highlighted? Because that’s as expected: it is the first line after the throw-statement (the throw-statement itself doesn’t “catch” the error for the debugger).

See screenshot: