Serialisierungsausnahme, die geworfen werden kann

8

Obwohl mir klar ist, dass es eine ähnliche Frage gibt ( Wie man ein serialisiert Ausnahmeobjekt in C #? ), und obwohl die Antworten auf dieser Seite hilfreich waren, lösten sie das Problem nicht genau oder beantworteten die gestellte Frage nicht.

Ich glaube, die Frage war, wie man das Objekt serialisiert, damit es in dasselbe Objekt rekonstruiert (deserialisiert) werden kann. Ich habe versucht, die Lösung von davogones und Antony Booth , aber Ohne das Hinzufügen der Basisklasse System.Exception auf der konsumierenden Seite (wie in: SerializationException: Exception ) ist es unmöglich, diese Typen (selbst) als tatsächliche Ausnahmeobjekte zu verwenden, die geworfen werden können.

Bevor ich fortfahre, lassen Sie mich diese letzte Aussage erklären. Ich habe versucht, Antony Booths Lösung zu verwenden > in einem Webdienst (der Dienst enthält die Definition für das serialisierbare Objekt), um zu versuchen, dass alle Benutzer dieselbe Ausnahme verwenden (hoffentlich einen wiederverwendbaren serialisierbaren Ausnahmetyp erstellen, anstatt ihn erneut zu erstellen).

Leider, da keiner der Typen explizit von System.Exception abgeleitet wird, können Sie nicht throw sie verwenden, was natürlich nützlich wäre. Wie ich oben erwähnt habe, scheint es, dass das Hinzufügen von : Exception zu der Typ-Klassendefinition auf der konsumierenden Seite das Werfen des Objekts erlaubt, aber das erfordert das Bearbeiten von automatisch erzeugtem WSDL / Web-Service-Code, der intuitiv wie ein schlecht / nicht aussieht -Haltbare Praxis für mich (korrigieren Sie mich, wenn ich falsch liege).

Meine erste Frage ist, wiederum, ist es möglich, System.Exception zu serialisieren oder einen abgeleiteten Typ zu erstellen, der serialisiert werden kann, und wenn es möglich ist, wie würde man so verfahren? Ich sollte erwähnen, dass ich mir angesehen habe, wie der offizielle Weg aussieht, die Exception wiederherzustellen. Objekt , aber ich fürchte, ich verstehe es nicht sehr gut.

Meine zweite Frage betrifft die Architektur von System.Exception selbst. Ich würde gerne wissen, warum der System.Exception -Typ als [Serializable] markiert ist, wenn er dokumentiert wurde und offensichtlich dafür ausgelegt wurde, dass er nicht richtig serialisiert wird (zumindest mit XML), weil er Data object implementiert IDictionary ?

Von MSDN:

  

F: Warum kann ich Hashtabellen nicht serialisieren?

     

A: Der XmlSerializer kann keine Klassen verarbeiten, die die IDictionary-Schnittstelle implementieren. Dies lag zum einen an Terminplaneinschränkungen und zum anderen daran, dass eine Hashtabelle im XSD-Typsystem kein Gegenstück hat. Die einzige Lösung besteht darin, eine benutzerdefinierte Hashtabelle zu implementieren, die die IDictionary-Schnittstelle nicht implementiert.

Angesichts dessen, dass XML ein neuer Standard für den Datentransport wird (offiziell von Microsoft empfohlen), scheint es absurd dumm zu sein, den einzigen Objekttyp in .NET, der geworfen werden kann, nicht zu lassen XML-serialisierbar.

Ich freue mich darauf, einige Gedanken von allen SO'rs zu hören (besonders, da dies mein erster Beitrag ist).

Wenn Sie Fragen haben oder Klärung benötigen, zögern Sie bitte nicht, mich zu informieren.

Hinweis: Ich habe gerade gefunden dieser SO Post , der ein paar Fragen zu beantworten scheint, aber ich denke, ich würde mich gerne selbst darauf einlassen. lassen Sie es mich wissen, wenn es einem Duplikat zu nahe kommt.

    
llaughlin 31.08.2010, 13:17
quelle

2 Antworten

1

Sie können eine von Exception abgeleitete Klasse erstellen und die Serialisierung und Deserialisierung selbst durchführen, indem Sie die ISerializable Schnittstelle.

Beispiel aus wrox-Foren , Unterklassen ApplicationException :

BEARBEITEN : Wie gezeigt, ist ApplicationException veraltet. Die Verwendung der Basis Exception Klasse sollte gut funktionieren.

%Vor%     
axel_c 31.08.2010, 13:38
quelle
0

Betrachten Sie zwei Klassen.

Die erste ist die serialisierbare ExceptionDescription-Klasse, die die zu serialisierenden Attribute implementieren muss und von nichts erbt. Die zweite ist CustomException, die von Exception erbt und einen einzelnen Verweis auf eine Instanz von ExceptionDescription hat. CustomException implementiert auch den "öffentlichen statischen impliziten Operator", sodass Sie natürlich zwischen den beiden Implementierungen wechseln können.

%Vor%     
Kyle Lahnakoski 25.10.2010 00:10
quelle

Tags und Links