Gibt es eine Möglichkeit, sicherzustellen, dass Dispose() bei der Deserialisierung einer IDisposable-Klasse für eine Ausnahme aufgerufen wird?

Question

In C# deserialisiere ich ein Objekt eines Typs, der IDisposable mit der folgenden Anweisung implementiert (nur zur Veranschaulichung).

afaik, der Serializer versucht, das Objekt mit dem Standard-Ctor zu konstruieren und anschließend alle öffentlichen Eigenschaften und Felder zuzuordnen. Falls eine Ausnahme ausgelöst wird, erhalte ich das konstruierte Objekt nicht.

Also, meine Frage ist, ob es einen Weg gibt, um sicherzustellen, dass noch zugewiesene Ressourcen automatisch freigegeben werden. Ich bin mir des Dispose (bool disposing) - "Musters" bewusst, das einen expliziten Finalizer implementiert, aber ich würde mich wohler damit fühlen, alle Ressourcen explizit (d. h. deterministisch) zu befreien.

Answer 1

Es scheint, den ungewöhnlichen Fall für ein DTO tatsächlich haben Ressourcen freizugeben, kann ich so verstehen, wenn es nicht IDisposable Support bietet bei Ausfall (meine eigenen Serializer nicht, entweder - so sicher, ich kann‘ t kritisieren).

Vielleicht ändern Sie Ihre Klasse, so dass, wenn es hat Ressourcen zu entsorgen, dauert es diese Ressourcen träge (d. H. Nicht nur, wenn der Typ deserialisiert).

XmlSerializer unterstützt keine Callbacks, sonst wäre der letzte Callback eine mögliche Option, Ressourcen schnell zu laden (ein bisschen hacky, obwohl).

Answer 2

Macht Ihr Standardkonstruktor etwas, das eine Entsorgung erfordern würde? Wenn ja, ist das eine gute Idee (besonders für ein Objekt, das in xml serialisiert werden soll)? Wenn nein, warum machst du dir dann Sorgen? Lassen Sie es für den Garbage Collector ...

[Edit: Entfernte Punkt über den öffentlichen Bereichen, da seine falsche]
Ich verlasse auch diese Antwort für jeden erzieherischen Wert es haben kann -> lesen Marcs

Answer 3

Wenn innerhalb der XmlSerializer.Deserialize Methode eine Ausnahme ausgelöst wird, wird sie an die nächste Fangmethode weitergegeben, und Ihr Objekt (o) wird nicht zugewiesen. Wenn Sie also die Eigenschaften-Setter nicht dazu verwenden, einige nicht verwaltete Ressourcen während der Deserialisierung zuzuweisen, sehe ich nicht, warum Sie sich darum kümmern sollten, das Objekt manuell zu entfernen.

Wenn Ihre Klasse jedoch nicht verwaltete Ressourcen zuweist, bedeutet die ordnungsgemäße Implementierung von IDisposable, dass Sie auch nicht verwaltete Ressourcen vom Finalizer Ihres Objekts freigeben, sodass dies ausreichen sollte. Es gibt keine andere Möglichkeit, Dispose() für ein Objekt aufzurufen, das nicht an erster Stelle zugewiesen wurde.

Nachdem ich das gesagt habe, musste ich mehrere Male XmlSerializer hängen, wenn die XML-Datei während der Deserialisierung nicht vollständig gültig war - also habe ich vor der Deserialisierung eine Schema-Validierung durchgeführt, um sicherzugehen, dass alles gut geht .

Answer 4

Wie wäre es mit GC.Collect (0, GCCollectionMode.Forced) nach Erhalt der Ausnahme?

Answer 5

A using Klausel ist, was Sie determinis freie Ressourcen nutzen:

using (MyDisposible o = (MyDisposible)s.Deserialize (filepath)) 
{ 
// Do stuff with 0 
} 

Ich würde fragen, warum Sie dies allerdings tun wollen. In C# wollen Sie nur Dinge deterministisch freigeben, wenn sie an eine externe physische Ressource wie eine SQL-Verbindung oder eine Datei gebunden sind.

Ein Garbage Collector ist asymptotisch effizienter als die manuelle Speicherverwaltung, und es empfiehlt sich, Speicherreferenzen einfach aus dem Bereich zu entfernen, um freigegeben zu werden.

Answer 6

Disposser und Finalizer sind NICHT das gleiche in C#.

Ein Disponent implementiert einen Aufruf, um die verwendeten Ressourcen explizit anzugeben, jedoch nicht den darin enthaltenen Speicher. Der Benutzer Ihres Objekts muss dies aufrufen.

Sie können einen Finalizer in C# verwenden, um sicherzustellen, dass selbst wenn Ihr Entsorger nicht aufgerufen wird, keine Ressourcen verloren gehen. d. Net garantiert, dass es versuchen wird, Ihren Entsorger laufen, bevor es tatsächlich Müll gesammelt.

XmlSerializer ist in seinem Aufruf verantwortlich, Speicher nicht zu verlieren, wenn eine Ausnahme in dem Aufruf ist. Wenn dies der Fall ist, haben Sie einen Fehler in .Net gefunden und können es melden. Wenn Sie deserialize aufrufen und es eine Ausnahme auslöst, erhalten Sie das Objekt nicht zurück, es ist weg ...

. Net Müllsammler funktioniert übrigens, es ist eine der Werbegeschenke, die Sie mit einer verwalteten Sprache erhalten, in dass Sie sich in den meisten Fällen keine Gedanken über die Bereinigung Ihres Speichers machen müssen, damit Sie sich mehr auf das konzentrieren können, was Ihr Code tut, und das richtig machen.