Ist es missbräuchlich, IDisposable und "using" als Mittel zu verwenden, um "Scoped Behaviour" für die Ausnahmesicherheit zu erhalten?

Etwas, das ich in C ++ oft verwendet habe, war, eine Klasse über den Konstruktor und den Destruktor Aeine Zustandseintritts- und -ausgangsbedingung für eine andere Klasse behandeln zu lassen, um sicherzustellen, dass B einen bekannten Zustand hat, wenn etwas in diesem Bereich eine Ausnahme auslöst Umfang wurde verlassen. Dies ist kein reines RAII, was das Akronym betrifft, aber es ist dennoch ein etabliertes Muster.BA

In C # möchte ich oft tun

class FrobbleManager
{
    ...

    private void FiddleTheFrobble()
    {
        this.Frobble.Unlock();
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
        this.Frobble.Lock();
    }
}

Was so gemacht werden muss

private void FiddleTheFrobble()
{
    this.Frobble.Unlock();

    try
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
    finally
    {
        this.Frobble.Lock();
    }
}

wenn ich den FrobbleZustand bei der FiddleTheFrobbleRückkehr garantieren will . Der Code wäre schöner mit

private void FiddleTheFrobble()
{
    using (var janitor = new FrobbleJanitor(this.Frobble))
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
}

wo FrobbleJanitorsieht ungefähr so aus

class FrobbleJanitor : IDisposable
{
    private Frobble frobble;

    public FrobbleJanitor(Frobble frobble)
    {
        this.frobble = frobble;
        this.frobble.Unlock();
    }

    public void Dispose()
    {
        this.frobble.Lock();
    }
}

Und so will ich es machen. Jetzt Realität einholt, da das, was ich will , um den Einsatz erfordert , dass der FrobbleJanitorverwendet wird , mit using . Ich könnte dies als ein Problem bei der Codeüberprüfung betrachten, aber etwas nervt mich.

Frage: Würde das oben Gesagte als missbräuchliche Verwendung von usingund angesehen IDisposable?

Ich denke nicht unbedingt. IDisposable technisch ist gemeint für Dinge verwendet werden , die nicht verwalteten Ressourcen haben, aber dann die using - Direktive ist nur eine nette Art und Weise ein gemeinsames Muster von der Implementierung try .. finally { dispose }.

Ein Purist würde argumentieren "Ja - es ist missbräuchlich", und im puristischen Sinne ist es; Aber die meisten von uns codieren nicht aus puristischer, sondern aus einer halbkünstlerischen Perspektive. Die Verwendung des Konstrukts "using" auf diese Weise ist meiner Meinung nach in der Tat ziemlich künstlerisch.

Sie sollten wahrscheinlich eine andere Schnittstelle auf IDisposable kleben, um sie etwas weiter wegzuschieben, und anderen Entwicklern erklären, warum diese Schnittstelle IDisposable impliziert.

Es gibt viele andere Alternativen dazu, aber letztendlich kann ich mir keine vorstellen, die so ordentlich sein wird, also machen Sie es!

Ich betrachte dies als Missbrauch der using-Anweisung. Mir ist bewusst, dass ich in dieser Position in der Minderheit bin.

Ich betrachte dies aus drei Gründen als Missbrauch.

Erstens, weil ich davon ausgehe, dass "using" verwendet wird, um eine Ressource zu verwenden und zu entsorgen, wenn Sie damit fertig sind . Das Ändern des Programmstatus verwendet keine Ressource und das Zurücksetzen ändert nichts. Daher ist das "Verwenden" zum Mutieren und Wiederherstellen des Zustands ein Missbrauch. Der Code ist für den Gelegenheitsleser irreführend.

Zweitens, weil ich erwarte, dass "Verwenden" aus Höflichkeit und nicht aus Notwendigkeit verwendet wird . Der Grund, warum Sie "using" verwenden, um eine Datei zu entsorgen, wenn Sie damit fertig sind, liegt nicht darin, dass dies erforderlich ist , sondern darin, dass es höflich ist - möglicherweise wartet jemand anderes darauf, diese Datei zu verwenden, und sagt "erledigt" jetzt "ist die moralisch korrekte Sache zu tun. Ich gehe davon aus, dass ich in der Lage sein sollte, eine "Verwendung" umzugestalten, damit die verwendete Ressource länger aufbewahrt und später entsorgt wird, und dass die einzige Auswirkung darin besteht, andere Prozesse geringfügig zu stören . Ein "using" -Block, der semantische Auswirkungen auf den Programmstatus hat ist missbräuchlich, weil es eine wichtige, erforderliche Mutation des Programmzustands in einem Konstrukt verbirgt, das so aussieht, als ob es der Bequemlichkeit und Höflichkeit dient, nicht der Notwendigkeit.

Und drittens werden die Aktionen Ihres Programms durch seinen Status bestimmt. Die Notwendigkeit einer sorgfältigen Manipulation des Staates ist genau der Grund, warum wir dieses Gespräch überhaupt führen. Lassen Sie uns überlegen, wie wir Ihr ursprüngliches Programm analysieren könnten.

Wenn Sie dies zu einer Codeüberprüfung in meinem Büro bringen würden, würde ich als erstes die Frage stellen: "Ist es wirklich richtig, das Frobble zu sperren, wenn eine Ausnahme ausgelöst wird?" Aus Ihrem Programm geht eindeutig hervor, dass dieses Ding das Frobble aggressiv wieder sperrt, egal was passiert. Ist das richtig? Eine Ausnahme wurde ausgelöst. Das Programm befindet sich in einem unbekannten Zustand. Wir wissen nicht, ob Foo, Fiddle oder Bar geworfen haben, warum sie geworfen haben oder welche Mutationen sie in einem anderen Zustand durchgeführt haben, der nicht aufgeräumt wurde. Können Sie mich davon überzeugen , dass es in dieser schrecklichen Situation immer das Richtige ist, erneut zu sperren?

Vielleicht ist es das, vielleicht ist es das nicht. Mein Punkt ist, dass der Code-Prüfer mit dem Code, wie er ursprünglich geschrieben wurde, die Frage stellen kann . Mit dem Code, der "using" verwendet, weiß ich nicht, ob ich die Frage stellen soll. Ich gehe davon aus, dass der "using" -Block eine Ressource zuweist, sie für eine Weile verwendet und höflich darüber verfügt, wenn dies erledigt ist, und nicht, dass die schließende Klammer des "using" -Blocks meinen Programmstatus unter außergewöhnlichen Umständen mutiert, wenn beliebig viele Die Konsistenzbedingungen des Programmstatus wurden verletzt.

Die Verwendung des "using" -Blocks für einen semantischen Effekt macht dieses Programmfragment:

}

äußerst bedeutungsvoll. Wenn ich mir diese einzelne enge Zahnspange ansehe, denke ich nicht sofort, "dass diese Zahnspange Nebenwirkungen hat, die weitreichende Auswirkungen auf den globalen Status meines Programms haben". Aber wenn Sie "Verwenden" so missbrauchen, geschieht dies plötzlich.

Das zweite, was ich fragen würde, wenn ich Ihren Originalcode sehen würde, ist "Was passiert, wenn eine Ausnahme nach dem Entsperren ausgelöst wird, aber bevor der Versuch eingegeben wird?" Wenn Sie eine nicht optimierte Assembly ausführen, hat der Compiler möglicherweise vor dem Versuch eine No-Op-Anweisung eingefügt, und es ist möglich, dass beim No-Op eine Thread-Abbruch-Ausnahme auftritt. Dies ist selten, aber im wirklichen Leben, insbesondere auf Webservern. In diesem Fall erfolgt die Entsperrung, die Sperre jedoch nie, da die Ausnahme vor dem Versuch ausgelöst wurde. Es ist durchaus möglich, dass dieser Code für dieses Problem anfällig ist und tatsächlich geschrieben werden sollte

bool needsLock = false;
try
{
    // must be carefully written so that needsLock is set
    // if and only if the unlock happened:

    this.Frobble.AtomicUnlock(ref needsLock);
    blah blah blah
}
finally
{
    if (needsLock) this.Frobble.Lock();
}

Wieder vielleicht, vielleicht auch nicht, aber ich weiß, dass ich die Frage stellen muss . Bei der "using" -Version tritt das gleiche Problem auf: Eine Thread-Abbruch-Ausnahme kann ausgelöst werden, nachdem das Frobble gesperrt wurde, aber bevor der mit der Verwendung verknüpfte try-geschützte Bereich eingegeben wird. Aber mit der "using" -Version gehe ich davon aus, dass dies ein "na und?" Ist. Lage. Es ist bedauerlich, wenn das passiert, aber ich gehe davon aus, dass das "Verwenden" nur dazu da ist, höflich zu sein, nicht um den lebenswichtigen Programmzustand zu mutieren. Ich gehe davon aus, dass der Garbage Collector diese Ressource schließlich durch Ausführen des Finalizers bereinigt, wenn eine schreckliche Ausnahme für den Thread-Abbruch genau zum falschen Zeitpunkt auftritt.

Wenn Sie nur sauberen Code mit Gültigkeitsbereich wünschen, können Sie auch Lambdas á la verwenden

myFribble.SafeExecute(() =>
    {
        myFribble.DangerDanger();
        myFribble.LiveOnTheEdge();
    });

wo die .SafeExecute(Action fribbleAction)Methode den try- catch- finallyBlock umschließt.

Eric Gunnerson, der Mitglied des C # -Sprachendesign-Teams war, gab diese Antwort auf fast dieselbe Frage:

Doug fragt:

re: Eine Sperranweisung mit Timeout ...

Ich habe diesen Trick schon einmal gemacht, um mit gängigen Mustern in zahlreichen Methoden umzugehen . Normalerweise Sperrenerfassung , aber es gibt einige andere . Das Problem ist, dass es sich immer wie ein Hack anfühlt, da das Objekt nicht wirklich verfügbar ist, sondern " am Ende eines Bereichs zurückgerufen werden kann ".

Doug,

Als wir uns für die using-Anweisung entschieden haben, haben wir beschlossen, sie "using" zu nennen und nicht etwas Spezifischeres für die Entsorgung von Objekten, damit sie für genau dieses Szenario verwendet werden kann.

Es ist ein rutschiger Hang. IDisposable hat einen Vertrag, der von einem Finalizer gesichert wird. Ein Finalizer ist in Ihrem Fall nutzlos. Sie können den Client nicht zwingen, die using-Anweisung zu verwenden, sondern ihn nur dazu ermutigen. Sie können es mit einer Methode wie der folgenden erzwingen:

void UseMeUnlocked(Action callback) {
  Unlock();
  try {
    callback();
  }
  finally {
    Lock();
  }
}

Aber das wird ohne Lamdas etwas unangenehm. Trotzdem habe ich IDisposable wie Sie verwendet.

Es gibt jedoch ein Detail in Ihrem Beitrag, das dies gefährlich nahe an ein Anti-Muster bringt. Sie haben erwähnt, dass diese Methoden eine Ausnahme auslösen können. Dies kann der Anrufer nicht ignorieren. Er kann drei Dinge dagegen tun:

• Tun Sie nichts, die Ausnahme kann nicht wiederhergestellt werden. Der Normalfall. Das Aufrufen von Unlock spielt keine Rolle.
• Fangen Sie die Ausnahme ab und behandeln Sie sie
• Stellen Sie den Status in seinem Code wieder her und lassen Sie die Ausnahme die Aufrufkette passieren.

Bei den beiden letzteren muss der Aufrufer explizit einen try-Block schreiben. Jetzt stört die using-Anweisung. Es kann durchaus dazu führen, dass ein Klient ins Koma fällt, was ihn glauben lässt, dass Ihre Klasse sich um den Staat kümmert und keine zusätzliche Arbeit geleistet werden muss. Das ist fast nie richtig.

Ein Beispiel aus der Praxis ist das BeginForm von ASP.net MVC. Grundsätzlich kann man schreiben:

Html.BeginForm(...);
Html.TextBox(...);
Html.EndForm();

oder

using(Html.BeginForm(...)){
    Html.TextBox(...);
}

Html.EndForm ruft Dispose auf, und Dispose gibt nur das </form>Tag aus. Das Gute daran ist, dass die {} Klammern einen sichtbaren "Bereich" erstellen, der es einfacher macht zu sehen, was sich im Formular befindet und was nicht.

Ich würde es nicht überbeanspruchen, aber im Wesentlichen ist IDisposable nur eine Möglichkeit zu sagen: "Sie MÜSSEN diese Funktion aufrufen, wenn Sie damit fertig sind." MvcForm verwendet es, um sicherzustellen, dass das Formular geschlossen ist. Stream verwendet es, um sicherzustellen, dass der Stream geschlossen ist. Sie können es verwenden, um sicherzustellen, dass das Objekt entsperrt ist.

Persönlich würde ich es nur verwenden, wenn die folgenden zwei Regeln wahr sind, aber die von mir willkürlich festgelegt werden:

• Dispose sollte eine Funktion sein, die immer ausgeführt werden muss, daher sollte es keine Bedingungen außer Null-Checks geben
• Nach Dispose () sollte das Objekt nicht wiederverwendbar sein. Wenn ich ein wiederverwendbares Objekt haben möchte, würde ich es lieber öffnen / schließen als entsorgen. Ich löse also eine InvalidOperationException aus, wenn ich versuche, ein entsorgtes Objekt zu verwenden.

Am Ende dreht sich alles um Erwartungen. Wenn ein Objekt IDisposable implementiert, gehe ich davon aus, dass es bereinigt werden muss, also nenne ich es. Ich denke, es ist normalerweise besser als eine "Shutdown" -Funktion.

Davon abgesehen mag ich diese Zeile nicht:

this.Frobble.Fiddle();

Da der FrobbleJanitor den Frobble jetzt "besitzt", frage ich mich, ob es nicht besser wäre, stattdessen Fiddle auf dem Frobble im Hausmeister anzurufen?

Wir haben dieses Muster in unserer Codebasis häufig verwendet, und ich habe es schon überall gesehen - ich bin sicher, dass es auch hier besprochen worden sein muss. Im Allgemeinen sehe ich nicht, was daran falsch ist, es liefert ein nützliches Muster und verursacht keinen wirklichen Schaden.

Ich stimme dem zu: Ich stimme den meisten hier zu, dass dies fragil, aber nützlich ist. Ich möchte Sie auf die System.Transaction.TransactionScope- Klasse verweisen , die so etwas tut, wie Sie es möchten.

Im Allgemeinen mag ich die Syntax, sie entfernt viel Unordnung aus dem echten Fleisch. Bitte geben Sie der Hilfsklasse einen guten Namen - vielleicht ... Umfang, wie im obigen Beispiel. Der Name sollte verraten, dass er einen Code einschließt. * Scope, * Block oder ähnliches sollte es tun.

Hinweis: Mein Standpunkt ist wahrscheinlich von meinem C ++ - Hintergrund abhängig, daher sollte der Wert meiner Antwort anhand dieser möglichen Abweichung bewertet werden ...

Was sagt die C # -Sprachspezifikation?

Zitieren der C # -Sprachspezifikation :

8.13 Die using-Anweisung

[...]

Eine Ressource ist eine Klasse oder Struktur, die System.IDisposable implementiert, die eine einzelne parameterlose Methode namens Dispose enthält. Code, der eine Ressource verwendet, kann Dispose aufrufen, um anzuzeigen, dass die Ressource nicht mehr benötigt wird. Wenn Dispose nicht aufgerufen wird, erfolgt die automatische Entsorgung möglicherweise als Folge der Speicherbereinigung.

Der Code, der eine Ressource verwendet, ist natürlich der Code, der mit dem usingSchlüsselwort beginnt und bis zu dem Bereich reicht, der an das angehängt ist using.

Ich denke, das ist in Ordnung, weil das Schloss eine Ressource ist.

Vielleicht wurde das Schlüsselwort usingschlecht gewählt. Vielleicht hätte es heißen sollen scoped.

Dann können wir fast alles als Ressource betrachten. Ein Dateihandle. Eine Netzwerkverbindung ... Ein Thread?

Ein Thread ???

Das usingSchlüsselwort verwenden (oder missbrauchen) ?

Wäre es glänzend , das usingSchlüsselwort (ab) zu verwenden , um sicherzustellen, dass die Arbeit des Threads beendet ist, bevor der Bereich verlassen wird?

Herb Sutter scheint zu denken, dass es glänzend ist , da er eine interessante Verwendung des IDispose-Musters anbietet, um auf das Ende der Arbeit eines Threads zu warten:

http://www.drdobbs.com/go-parallel/article/showArticle.jhtml?articleID=225700095

Hier ist der Code, der aus dem Artikel kopiert wurde:

// C# example
using( Active a = new Active() ) {    // creates private thread
       …
       a.SomeWork();                  // enqueues work
       …
       a.MoreWork();                   // enqueues work
       …
} // waits for work to complete and joins with private thread

Während der C # -Code für das aktive Objekt nicht bereitgestellt wird, wird geschrieben, dass das C # das IDispose-Muster für den Code verwendet, dessen C ++ - Version im Destruktor enthalten ist. Wenn wir uns die C ++ - Version ansehen, sehen wir einen Destruktor, der darauf wartet, dass der interne Thread beendet wird, bevor er beendet wird, wie in diesem anderen Auszug des Artikels gezeigt:

~Active() {
    // etc.
    thd->join();
 }

Für Herb ist es also glänzend .

Ich glaube, die Antwort auf Ihre Frage ist nein, dies wäre kein Missbrauch von IDisposable.

Ich verstehe die IDisposableSchnittstelle so, dass Sie nach der Entsorgung nicht mehr mit einem Objekt arbeiten sollen (außer dass Sie seine DisposeMethode so oft aufrufen dürfen, wie Sie möchten).

Da Sie jedes Mal, wenn Sie zur Anweisung gelangen, explizit ein neues Objekt erstellen , verwenden Sie dasselbe Objekt niemals zweimal. Und da der Zweck darin besteht, ein anderes Objekt zu verwalten, erscheint dies für die Aufgabe der Freigabe dieser ("verwalteten") Ressource angemessen.FrobbleJanitorusingFrobbeJanitorDispose

(Übrigens Disposeschlägt der Standard-Beispielcode, der die ordnungsgemäße Implementierung von fast immer demonstriert, vor, dass auch verwaltete Ressourcen freigegeben werden sollten, nicht nur nicht verwaltete Ressourcen wie Dateisystemhandles.)

Das einzige, worüber ich mir persönlich Sorgen machen würde, ist, dass es weniger klar ist, was passiert, using (var janitor = new FrobbleJanitor())als mit einem expliziteren try..finallyBlock, in dem die Lock& Unlock-Operationen direkt sichtbar sind. Aber welcher Ansatz gewählt wird, hängt wahrscheinlich von den persönlichen Vorlieben ab.

Es ist nicht missbräuchlich. Sie verwenden sie, wofür sie erstellt wurden. Möglicherweise müssen Sie jedoch je nach Ihren Anforderungen aufeinander eingehen. Wenn Sie sich beispielsweise für 'Artistik' entscheiden, können Sie 'using' verwenden. Wenn Ihr Code jedoch häufig ausgeführt wird, können Sie aus Leistungsgründen die Konstrukte 'try' .. 'finally' verwenden. Weil 'Verwenden' normalerweise das Erstellen eines Objekts beinhaltet.

Ich denke du hast es richtig gemacht. Das Überladen von Dispose () wäre ein Problem, das dieselbe Klasse später tatsächlich bereinigen musste, und die Lebensdauer dieser Bereinigung änderte sich anders als die Zeit, zu der Sie voraussichtlich eine Sperre halten. Da Sie jedoch eine separate Klasse (FrobbleJanitor) erstellt haben, die nur für das Sperren und Entsperren des Frobble verantwortlich ist, sind die Dinge so weit entkoppelt, dass Sie dieses Problem nicht lösen.

Ich würde FrobbleJanitor jedoch umbenennen, wahrscheinlich in etwas wie FrobbleLockSession.