Neugierige C# mit Anweisungserweiterung

Question

Ich habe ildasm ausgeführt, um dies festzustellen:

    using(Simple simp = new Simple())
    {
        Console.WriteLine("here");
    }

erzeugt IL-Code, der dem hier entspricht:

    Simple simp = new Simple();
    try
    {
        Console.WriteLine("here");
    }
    finally
    {
        if(simp != null)
        {
            simp.Dispose();
        }
    }

und die Frage ist, warum zur Hölle prüft es null in der finally? Der finally-Block wird nur ausgeführt, wenn der try-Block ausgeführt wird, und der try-Block wird nur ausgeführt, wenn der Simple-Konstruktor erfolgreich ist (d.h. keine Exception auslöst), in diesem Fall wird simp nicht null sein. (Wenn zu befürchten ist, dass zwischen dem Simple-Konstruktor und dem Beginn des Try-Blocks einige Zwischenschritte liegen, dann wäre das wirklich ein Problem, denn dann könnte eine Ausnahme ausgelöst werden, die die Ausführung des Finally-Blocks überhaupt verhindert). Also, warum zum Teufel?

Abgesehen von der Frage, ob die using-Anweisung besser ist als try-finally, schreibe ich meine try-finally-Blöcke wie folgt:

    Simple simp = new Simple();
    try
    {
        Console.WriteLine("here");
    }
    finally
    {
        simp.Dispose();
        simp = null;        // sanity-check in case I touch simp again
                            // because I don't rely on all classes
                            // necessarily throwing
                            // ObjectDisposedException
    }

Answer 1

Nein, der finally-Block wird IMMER ausgeführt. Möglicherweise erhalten Sie das Objekt nicht von einem new, sondern von einer anderen Funktion, die Ihr Objekt zurückgibt - und diese könnte NULL zurückgeben. using() ist Ihr Freund!

dss539 war so freundlich, mir vorzuschlagen, seine Notiz aufzunehmen:

using(Simple simp = null) 

ist ein weiterer Grund dafür, dass die Erweiterung zuerst auf Null geprüft werden muss.

Answer 2

using(Simple simp = null) ist noch eine andere Grund, dass die Erweiterung zuerst auf Null prüfen muss.

Answer 3

MSDN bei der using-Anweisung.

Was ich seltsam finde, ist, dass sie sich nicht ausdehnen lässt:

Simple simp = new Simple();
Simple __compilergeneratedtmpname = simp;
try
{
    Console.WriteLine("here");
}
finally
{
    if(__compilergeneratedtmpname != null)
    {
        __compilergeneratedtmpname.Dispose();
    }
}

Answer 4

Es scheint, dass Ihr Kommentar:

"Wenn zu befürchten ist, dass zwischen dem Simple-Konstruktor und dem Beginn des Try-Blocks einige Zwischenschritte liegen, wäre das wirklich ein Problem, denn dann könnte eine Ausnahme ausgelöst werden, die verhindert, dass der Finally-Block überhaupt ausgeführt werden kann."

ist möglicherweise goldrichtig. Siehe:

Atomarität und asynchrone Fehlfunktionen von Ausnahmen

Ich möchte auch das Problem (die Probleme) mit WCF und mit beachten:

Vermeiden von Problemen mit der Using-Anweisung und WCF Service Proxies auf die Bezug genommen wird:

Vermeiden von Problemen mit der Using-Anweisung

Answer 5

Der Code muss auf diese Weise übersetzt werden, um eine mögliche NullReferenceException wenn das Objekt entsorgt wird. Gemäß C#-Sprachreferenz El Anweisung verwenden akzeptiert nicht nur die Deklaration einer lokalen Variable als erstes Nichtterminal resource_acquisition Symbol, sondern jedes Ausdruck . Betrachten Sie den folgenden Code:

DisposableType @object = null;
using(@object) {
    // whatever
}

Es liegt auf der Hand, dass, sofern keine Null-Bedingung @object?.Dispose() im finnaly blockieren, würde es zu einer Ausnahme kommen. Die Nullprüfung ist nur dann überflüssig, wenn die Ausdruck von einem nicht-nullbaren Werttyp ist (nicht-nullbare Struktur). Und in der Tat, nach der oben erwähnten Sprachreferenz fehlt sie in einem solchen Fall.