Die PROCEDURE READNODE kann nicht funktionieren,
weil das Object XmlDoc nicht bekannt ist.
Na ja, die Prozedur könnte eine lokale Prozedur sein, oder XmlDoc ist ein Feld einer Klasse oder eine globale Variable oder es war einfach nur Pseudocode und sollte nur den Sinn von Refactoring und DRY demonstrieren. In jedem Fall hast Du natürlich recht, sie kann nicht funktionieren: Ich habe sie nämlich noch gar nicht gespeichert
Zitat:
Dieser sinnlose VERBESSERUNGSTRIEB
Wenn das für dich sinnlos ist, dann weiß ich auch nicht. Aber jeder soll so programmieren, wie er es für richtig hält. Das Lustige an DRY ist übrigens, das Du die Prozedur 'ReadNode' ohne Probleme anpassen kannst (z.B. den Fehler loggen), und zwar an dieser einen Stelle. Alle Aufrufe werden sich automatisch und logischerweise dann genau gleich verhalten. Bei deiner Copy&Paste-Vorgehensweise müsstest Du dann an allen Stellen das gleiche machen und wehe Du vertippst dich oder vergisst eine Stelle.
Denk mal drüber nach. Und wenn Du schon dabei bist (am Nachdenken), überlege Dir auch noch, ob dich überhaupt jemand kritisiert hat und wieso Du hier so ausrastest. Ich wollte Dir jedenfalls nicht an den Karren pissen.
...dass ich die Methode eher PrintNode
oder 'ProcessNode' oder so.
Das
Handle-Beispiel könnte man auch so lösen, das die 'GetHandleFromElsewhere'-Methode die
Exception-Behandlung übernimmt. Oder man macht soetwas:
LHandle1 := CheckHandle (GetHandleFromElseWhere, 'From ElseWhere');
LHandle2 := CheckHandle (GetHandleFromElseWhere (LHandle1), 'From ElseWhere 1');
LHandle3 := CheckHandle (GetHandleFromElseWhere (LHandle2), 'From ElseWhere 2');
LHandle4 := CheckHandle (GetHandleFromElseWhere (LHandle3), 'From ElseWhere 3');
...
Wobei das CheckHandle eine Funktion ist:
Delphi-Quellcode:
Function CheckHandle (aHandle : THandle; Msg :
String) : THandle;
Begin
if aHandle = InvalidHandle
then Raise Exception.Create(Msg);
result := aHandle;
End;
Macht Delphi z.T. ja auch so.
Ich persönlich finde das aber nicht sooo lesbar. Es ist zu empfehlen, wenn man die GetXXXX-Funktionen nicht ändern kann.
Man kann die aber Kapseln, sodaß die
Exception-Behandlung im Wrapper stattfindet. Solch ein Code (3-Zeiler) kann ruhig komisch aussehen, da schaut man kurz rein, sagt:'Ach so' und macht das Zeugs wieder zu. Die Wrapper sind dann aber sehr gut zu lesen:
Delphi-Quellcode:
Try
LHandle1 := GetHandle;
LHandle2 := GetHandle(LHandle1);
LHandle3 := GetHandle(LHandle2);
LHandle4 := GetHandle(LHandle3);
DoSomething(LHandle1,LHandle2,LHandle3,LHandle4);
Except
On E:EInvalidHandle Do begin
LogError(E);
Raise EMoreAbstractException.Create(E);
End;
End;
Und das ist dann schon wieder schön knackig.
Die 'EMoreAbstractException' analysiert die innere
Exception (kann ja unterschiedliche Gründe haben) und erzeugt eine
Exception, die die Details verschweigt. Der Aufrufer interessiert sich ja nicht dafür, das der USB-Treiber aufgrund ungültiger Installationsparameter im 3.Duktus links kein
Handle bereitstellen kann. Wichtig ist: 'Es funzt net'. Details stehen im Log.
@JasonDX: Wenn da wirklich nur ein Return erfolgen soll, ist das grenzwertig. Meist ist so ein stillschweigendes Scheitern schlechter Stil. WENN es aber genaus so sein soll, ist das mit dem Return schon so richtig.
Da ginge aber auch (besser?) sowas:
Delphi-Quellcode:
if not TryGetHandle (LHandle1) then return;
if not TryGetHandle (LHandle1,LHandle2) then return;
if not TryGetHandle (LHandle2,LHandle3) then return;
if not TryGetHandle (LHandle3,LHandle4) then return;
Wieder knackig kompakt