Try Finally End verlassen bzw. abbrechen

[stahli]

Ich habe das missverständlich formuliert.
Verbale Rückmeldung und Ruhen lassen des Threads reicht aus. Ein Erledigt-Flag oder Abschließen des Threads ist nicht notwending.

[himitsu]

Ein Manifest welches ensprechende (Admin)Rechte anfordert,
oder ein externer Aufruf z.B. über Runas, oder über Eigenschaften von Verknüpfungen (lnk), oder der zugeordnete Benutzerkonto eines Services usw.


Wenn man das unbedingt markieren will, dann kann man beim Erstellen einer Frage diese als "offen" markieren und das später wieder weg machen,
oder schreibt einfach, daß und eventuell welche Lösung man genommen hat.

[Dejan Vu]

Ich würde das so lösen:

Delphi-Quellcode:

Procedure TForm1.BtnStartClick(Sender: TObject);
Const
   DummySpace   ='C:\$space';

   Procedure _DemandDirectoryCreated(string aDirectory);
   Begin
      CreateDir(aDirectory);
      if Not DirectoryExists(aDirectory) Then
         Abort;
   end;

Begin
   BtnStart.Enabled:=False;
   MELog.Lines.Clear;
   Try
      MELog.Lines.Append('Step 1: Allocating Memory');
      MELog.Lines.Append('- creating directory "' + DummySpace + '"');

      _DemandDirectoryCreated(DummySpace);
      
     MELog.Lines.Append(' success...');
      // Hier nur weiter, wenn Verzeichnis angelegt wurde/existiert

   Except
      MELog.Lines.Append(' Could not create "' + DummySpace + '".');
      MELog.Lines.Append(' Error was: "' + SysErrorMessage(GetLastError) + '"');
      MELog.Lines.Append(' Opreation aborted.');
   End;
   BtnStart.Enabled:=True;
End;

[Sir Rufo]

@Dejan Vu

Das kann evtl. funktionieren, allerdings muss der Aufruf von GetLastError direkt im Anschluss der Funktion aufgerufen werden, wo dieser Fehler (hier CreateDir ) aufgetreten ist.

Ansonsten ist nicht gewährleistet, dass man auch wirklich die Fehlermeldung bekommt, die man eigentlich haben möchte.

EDIT
Eigentlich arbeitet GetLastError nur dann zuverlässig, wenn man gesichert direkt vorher eine Windows-Funktion aufgerufen hat.

Bei SysUtils.CreateDir kann man sich da aber nicht wirklich sicher sein ...

Delphi-Quellcode:

type
  // Wenn ein Arbeitsschritt fehlschlägt, dann diese Exception werfen
  EStepException = class(Exception);

procedure TForm1.BtnStartClick( Sender : TObject );
begin
  BtnStart.Enabled := False;
  try
    try

      MELog.Lines.Append('Step 1: Allocating Memory');
      MELog.Lines.Append('- creating directory "' + DummySpace + '"');

      if ForceDirectories( DummySpace )
      then
        MELog.Lines.Append( ' success' )
      else
        raise EStepException.CreateFmt( 'Could not create "%s"', [DummySpace] );

      // nächste Schritte

    except
      on E: EStepException do
        begin
          MELog.Lines.Append( E.Message );
          MELog.Lines.Append( 'Operation aborted.' );
          raise;
        end;
    end;
  finally
    BtnStart.Enabled := True;
  end;
end;

[Dejan Vu]

Zitat von Sir Rufo:

...allerdings muss der Aufruf von GetLastError direkt im Anschluss der Funktion aufgerufen werden, wo dieser Fehler (hier CreateDir ) aufgetreten ist.

Korrekt. War mir da auch nicht sicher. Mir ging es primär um den Kontrollfluss (exceptions, statt IF-Schl... Verzweigungen). Aber wenn man Code postet, sollte der schon 100% richtig sein. Und 'ForceDirectories' hatte ich nicht mehr auf dem Schirm.

Leider ist Delphi da noch nicht konsequent und bietet durchweg Methoden an, die knallen, anstatt einen Rückgabewert zu liefern. Dann dadurch wird man ja gerade dazu verleitet, IF-THEN-Verschachtelngsorgien zu 'feiern'.

Gehört hier aber nicht hin.

[himitsu]

Exceptions sind nicht zur standardmäßigen Flusssteuerung vorgesehen und vorallem beim Debuggen fällt man mit soeinem Schrott einfach nur voll auf die Fresse.

Wobei hier das ja auch als Ausnahme gesehen werden kann, wenn man auf das Verzeichnis nicht zugreifen kann und demnach nachfolgene Operationen, welche ja die Hauptfunktionalität darstellen, nicht mehr ausführbar sind.

[Dejan Vu]

Zitat von himitsu:

Exceptions sind nicht zur standardmäßigen Flusssteuerung vorgesehen

Doch. In der modernen Softwarearchitektur schon.

Edit: 'standardmäßigen' ist das Zauberwort. Da hast Du recht. Aber es war ein ungünstiger Kommentar zu einem imho legitimen Einsatz von Exceptions.

Ich bezeichne das als happy path programming. Der Kontrollfluß zeigt, wie es im Normalfall (der happy path) aussieht und die Ausnahmen hüpfen einfach raus (bzw. in den Except/Finally Teil).

[mkinzler]

Zitat von Dejan Vu:

Zitat von himitsu:

Exceptions sind nicht zur standardmäßigen Flusssteuerung vorgesehen

Doch. In der modernen Softwarearchitektur schon.

Also fahren nach Gehör!

[BUG]

Der Fall, das ein Verzeichnis nicht angelegt werden kann und nicht existiert, ist meiner Meinung nach eine ziemliche Ausnahme (abgesehen von merkwürdigen Ordner-Namen oder nicht existierenden Eltern-Ordnern, die sollte man vielleicht vorher abfangen).
Außerdem wird die Operation abgebrochen und ein Log-Eintrag dazu angelegt.

Was muss noch alles dazu kommen, das eine Exception gerechtfertigt ist? Random Memory Corruption?

[Dejan Vu]

Zitat von mkinzler:

Zitat von Dejan Vu:

Doch. In der modernen Softwarearchitektur schon.

Also fahren nach Gehör!

Eher übersichtlichen Code produzieren!

Zitat von BUG:

Der Fall, das ein Verzeichnis nicht angelegt werden kann und nicht existiert...

Hat mich auch gewundert. Aber wenn Du das Verzeichnis anlegst und dann wird die Festplatte ausgetauscht?....