Ich habe als Eingabe eine XML Datei, die in Objekte umgewandelt werden soll.
Dabei schön nach OOP. Also jedes Objekt parst den Teil, der es selbst darstellt.
Bsp:

Wären also 3 Objekte: Top, Subs (Objektliste) und Sub
Top parst seine Id, erstellt sich nen Wrapper für die Objektliste Subs und übergibt der das subs element. Das macht weiter, erstellt sich pro sub ein objekt und übergibt denen jeweils ein sub Element.

Jetzt kann es aber passieren, dass die XML-Datei ungültig ist (e.g. es fehlen Eigenschaften)
Mein Bisheriger Ansatz sieht vor, beim Fehlen einer Eigenschaft ne Exception auszulösen und die von der Methode abfangen zu lassen, die das Parsen angestoßen hat. Hab aber Bedenken, dass die Lösung gut ist.
Hat da jemand eine bessere Idee?

Flamefire hat folgendes geschrieben :

Hab aber Bedenken, dass die Lösung gut ist.

hmmm, dann verwirf Sie gleich wieder

Flamefire hat folgendes geschrieben :

Hat da jemand eine bessere Idee?

Im Prinzip durchaus schon richtig. Nur sollte die Routine die Exception halt auch durchreichen nach oben, inklusive zusätzlicher Informationen wo der Fehler auftrat.

Also z.B.:
Fehler beim Erstellen von ID-Objekt:
Fehler beim Erstellen von Subs-Objekt:
Fehler beim Erstellen von Sub-Objekt 1:
Fehlende Eigenschaft foo.

Dazu noch nen Stacktrace im Java-Style und die Meldung gibt auf jeden Fall Aufschluss, was Schiefgelaufen ist. Fehlt noch die Angabe zum Tag, wo der Fehler war, aber das kann man ja durchaus auch noch anhängen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

hm. Dann müsste ich meine For-Schleifen noch in while schleifen umbasteln. Sonst hab ich in jedem Schleifendurchlauf den ExceptionHandler-Code drin --> Unperformant.
Aber im Prinzip hatte ich dran auch schon gedacht:
Exception werfen: ID fehlt
Abfangen, neu werfen: ID fehlt in Sub 1
Abfangen, neu werfen: Fehler bei Subs: ID fehlt in Sub 1
usw.
Nur ist die Frage, ob ich wissen muss, dass es in Sub Objekt 1 aufgetreten ist. Es reicht eigentlich zu wissen, DASS ne Id im Sub objekt fehlt. Dann spar ich mir die exzessiven try-Blöcke

Mitunter ist es durchaus wichtig, die exakte Position von einem z.B. Parsing-Fehler zu kennen, da man dann z.B. bei Konfig-Dateien oder Datendateien direkt nachgucken kann, wo der fehlerhafte Block ist und damit schneller auch Debuggen kann.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ich würde hier Separation of Concerns anwenden. Deine Datenklasse muss nichts von Serialisierung wissen. Die Serialisierung muss nicht unbedingt Validierung machen. Konkret:

- Datenklassen ohne Serialisierungslogik. Allenfalls spezielle Serialisierungskonfigurationen deklarativ (ab Delphi 2010 mit Attributen) oder über opt-in.
=> Serialisierungslogik ist nicht über x Klassen verteilt mit wiederholendem Inhalt. Ausserdem ist XML nur eine Art von Serialisierung. Das sollte getrennt und generisch gelöst sein.

- Validierung über XSD o.ä. (Attribute wären auch eine Möglichkeit, die wäre XML unabhängig)
=> Du kannst dann z.B. auch grad deklarativ angeben, dass die Id ein Integer ist und nicht negativ sein darf. Keine if's verteilt im Code sondern alles in einem File.
=> Du kriegst IntelliSense in guten Editoren.
=> Du kriegst (je nach Parser) Rückmeldung, bevor die Hälfte der Struktur instanziiert ist. Zeilennummer etc. kriegste im Normalfall auch.

- Serialisierung/Deserialisierung als separate Funktionalität über RTTI oder Registrierungsmechanismus
=> Das programmierst du nur einmal für alle zukünftigen Projekte oder suchst dir eine Library
=> Wenn du satt XML einen JSon Serializer bauen willst, musst du keine deiner Klassen anfassen.