Design Problem: Exceptions in einer Schleife

[Luckie]

Ich habe eine Routine:

Delphi-Quellcode:

function TProcess.SetPriorityClass: DWORD;
var
  hProcess: THandle;
begin
  Result := 0;
  hProcess := OpenProcess(PROCESS_QUERY_INFORMATION, False, FProcID);
  if hProcess <> 0 then
  begin
    Result := Windows.GetPriorityClass(hProcess);
    CloseHandle(hProcess);
  end
  else
    raise TMpuProcToolException.Create(SysErrorMessage(GetLastError), GetLastError);
end;

Diese wirft im Fehlerfall eine Exception. Schön und gut, das tut sie auch. Nur leider wird diese Funktion in einer Schleife aufgerufen und wenn die Exception geworfen wird, fliege ich ganz aus der Schleife raus:

Delphi-Quellcode:

ProcList := TProcessList.Create(False);
  try
    try
      ProcList.EnableDebugPrivileges;
      ProcList.EnumProcesses;
      for i := 0 to ProcList.Count - 1 do
      begin
        s := ExtractFilename(ProcList.Items[i].ModuleFilename) + #9;
        s := s + Format('0x%.8X', [ProcList.Items[i].ProcessPriority]);
        Writeln(IntToStr(ProcList.Items[i].ProcID) + #9 + s);
      end;
    except
      on E: TMpuProcToolException do
        Writeln(E.Message);
    end;
  finally
    ProcList.Free;
  end;

Die Schleife steckt in der Methode ProcList.EnumProcesses:

Delphi-Quellcode:

procedure TProcessList.EnumProcesses;
var
  PIDList           : array[0..1024] of DWORD;
  Needed            : DWORD;
  i                 : Integer;
  Process           : TProcess;
begin
  if Psapi.EnumProcesses(@PIDList, sizeof(PIDList), Needed) then
  begin
    for i := 0 to Needed div sizeof(DWORD) - 1 do
    begin
      Process := TProcess.Create(PIDList[i]);
      FProcessList.Add(Process);
    end;
  end
  else
    raise TMpuProcToolException.Create(SysErrorMessage(GetLastError), GetLastError);
end;

Und das ist natürlich blöd, dass ich bei der Exceptions aus der Schleife fliege.

Was kann man da am Design machen, dass ich nicht aus der Schleife fliege, aber trotzdem irgendwie an die Exception-Nachricht drankomme, um sie anzeigen zu können?

[stoxx]

versteh ich gerade nicht..

Delphi-Quellcode:

for ..
begin
    try
    .... Code
    except
    .... Message
    end // except
end; // for

[Luckie]

Die Exceptions können im Constructor von TProcess auftreten, wenn die Eigenschaften ermittelt werden:

Delphi-Quellcode:

constructor TProcess.Create(PID: DWORD);
begin
  FProcID := PID;
  FModuleFilename := SetModuleFilename;
  FOwnerName := SetOwnerName; // Sets also FPOwnerSID, FOwnerStrSID
  FPriorityClass := SetPriorityClass;
end;

Deswegen, ich weiß nicht, ob deine Idee die Lösung ist. In dem Design steckt irgendwie der Wurm drine.

[Christian Seehase]

Moin Michael,

da sehe ich zwei Möglichkeiten:

1. Du kapselst den Methodenaufruf direkt in einen try/except-Block.
2. Du wirfst in der Methode keine Exception, sondern setzt einen Fehlercode.
   Soll der Fehlercode als Rückgabewert dienen, kannst Du das Ergebnis ja in einem var-Parameter zurückliefern, ansonsten könntest Du auch ein Feld der Klasse dafür benutzen, sozusagen ein klassenspezifischer LastError.

BTW:
Sollte die Methode nicht besser GetPriorityClass heissen?

[Luckie]

Zur Namensgebung:
Get und Set sind normalerwiese die Getter und Setter für die Eigenschaften. Da es aber keinen Sinn macht die Eigenschaft ProcID zu setzen, gibt es den Setter nicht. Für mich sind deshalb die Set-Funktionen, die Funktionen, die den Wert ermitteln und dem Attribut zu weisen.

Auf Fehlercodes wollte ich nicht zurückgreifen, weil das für mich keine sauberer OOP-Lösung wäre.

Zu deiner ersten Lösung: Das würde bedeuten ich müsste jeden Methoden aufruf zum Setzen der Attribute in einen try-except-Block kapseln. Hm, wäre möglich, sieht aber ziemlich blöd aus. Und was blöd aussieht ist meist auch falsch, für mich.

[Christian Seehase]

Moin Michael,

wenn Du Exceptions verwendest, bleibt Dir wohl nichts anderes übrig als diese auch dort abzufangen, wo sie auftreten können

Zitat von Luckie:

Get und Set sind normalerwiese die Getter und Setter für die Eigenschaften.

Klar.

Zitat von Luckie:

Da es aber keinen Sinn macht die Eigenschaft ProcID zu setzen, gibt es den Setter nicht.

Auch klar.

Zitat von Luckie:

Für mich sind deshalb die Set-Funktionen, die Funktionen, die den Wert ermitteln und dem Attribut zu weisen.

Aber darüber solltest Du noch mal nachdenken

Ich finde, dass sollte so aussehen:

property EineEigenschaft : TEinTyp read GetEineEigenschaft write SetEineEigenschaft; Was dann zur Folge hat, dass die Implementierung so aussieht:

Delphi-Quellcode:

function TEineKlasse.GetEineEigenschaft : TEinTyp;
begin
  Result := FEinFeld;
end;

procedure TEineKlasse.SetEineEigenschaft(Value:TEinTyp);
begin
  FEinFeld := Value;
end;

Bei Dir sieht das aber, aller Voraussicht nach, so aus:

property PriorityClass : DWORD read SetPriorityClass; Und wenn ich mir Deinen Konstruktor so anschaue:
Die Getter-Methoden dienen dazu die Eigenschaften auszulesen, und nicht dazu die zugehörigen Felder zu initialisieren.
Das könnte schon deshalb nicht funktionieren, da ja ein Getter, eigentlich, den Feldinhalt ausliest.

[Luckie]

Also für mich waren immer die Getter, die den Wert der Eigenscgaft zurückliefern und die Setter setzen sie. Oder verstehe ich da jetzt was falsch.

Und bei mir sieht es so aus:
property Eigenschaft: TSomeType read GetEigenschaft Also nur Read-only Eigenschaften.

Und die Exceptions dort abzufangen, wo sie auftreten widerspricht der Verwendung von Exceptions. Der Anwender des Codes sollte entscheiden, was er mit den Exceptions macht. Deswegen habe ich auch eine eigene Exceptionsklasse, damit der Programmierer die Exceptions filtern kann.

[Christian Seehase]

Moin Michael,

Zitat von Luckie:

Also für mich waren immer die Getter, die den Wert der Eigenscgaft zurückliefern und die Setter setzen sie.

Sag' ich doch.
Du hast es, soweit ich das sehen kann, aber anders herum gemacht, denn das Auslesen von ProcessPriority machst Du über SetProcessPriority
Zumindest sieht Dein Konstruktor für mich etwas seltsam aus...

Zitat von Luckie:

Und die Exceptions dort abzufangen, wo sie auftreten widerspricht der Verwendung von Exceptions.

Wo sonst willst Du sie abfangen? (von einem globlen Exception-Handler mal abgesehen, der in Deinem Beispiel aber keinen Sinn macht)

Zitat von Luckie:

Der Anwender des Codes sollte entscheiden, was er mit den Exceptions macht.

Richtig. In dem von Dir genannten Falle, (lesen von ProcessPriority in der Schleife) bist Du dann selber der Anwender.
Und Du fängst die Exception ja auch ab, nur eben nach der Schleife, was aber für den konkreten Anwendungsfall wenig hilfreich ist.
Wenn Du unmittelbar die Zeile in try/except kapselst, die den Fehler bekommen kann, kannst Du ja im Except-Abschnitt entsprechend reagieren, z.B., einen entsprechendes Flag in der dem gerade aktuellen Eintrag der Prozessliste setzen.
Eine andere Variante: Du baust Dir eine Liste auf für alle Prozess-IDs, bei denen eine Exception ausgelöst wurde.
Da ich davon ausgehe, dass der Aufbau der Liste mit zu einer Deiner Klassen gehört, könntest Du dann, für den Fall, dass mindestens ein Fehler aufgetreten ist, nach der Schleife, wiederum eine Exception auslösen, um dies kenntlich zu machen.
Wenn sich hingegegen ein Anwender der Klasse eine Prozessliste aufbauen will, ist es dessen Problem, wie er das handelt.

[Luckie]

Zitat von Christian Seehase:

denn das Auslesen von ProcessPriority machst Du über SetProcessPriority

Richtig und setze damit den Wert der Eigenschaft. Eine bessere Bezeichnung ist mir nicht eingefallen. Mich stört die Vorsilbe Set auch etwas.

Zitat:

Du baust Dir eine Liste auf für alle Prozess-IDs, bei denen eine Exception ausgelöst wurde.
Da ich davon ausgehe, dass der Aufbau der Liste mit zu einer Deiner Klassen gehört, könntest Du dann, für den Fall, dass mindestens ein Fehler aufgetreten ist, nach der Schleife, wiederum eine Exception auslösen, um dies kenntlich zu machen.

Das kling gut. Ich glaube so mache ich es.

[Christian Seehase]

Moin Michael,

Zitat von Luckie:

Richtig und setze damit den Wert der Eigenschaft.

eben nicht. Du setzt damit den Wert des Feldes, nicht den der Eigenschaft.
Eine Setter-Methode schreibt zwar den Wert eines Feldes, dass dann von aussen als Eigenschaft zugänglich ist, aber:
Hier erfolgt der Zugriff auf das Feld innerhalb der Methode.

Wie sieht denn die Deklaration der Eigenschaft ProcessPriority aus?