Try except - Functions - wie tief

[BMI]

ÜBERARBEITET und daher komplett anderer Zusammenhang, aber ich lasse hier alles stehen, um die Quotes stimmig zu halten.

Ich bitte Euch, wegen dem Code den Beitrag 10 unten anzuschauen
Überarbeitet - weiter unten hier im Thread:

Bitte Hier klicken !

http://www.delphipraxis.net/184074-try-except-functions-wie-tief.html#post1291202

[Spoiler]Hi,
ich hab jetzt herumgewurschtelt, aber so richtig sicher bin ich mir nicht:
Wie tief kann man functions mit Try verschachteln?
Ich würde gerne eine "erste" Function aufrufen, die eine zweite aufruft, in der eine systemkritische Operation durchgeführt wird.

Allerdings soll bis zur Button-Procedure die Rückmeldung über Erfolg/Fail zurückgeleitet werden.
Quasi irgendwo ein Result aus der zuvor abgearbeiteten Funktion.
Gesehen hab ich das schon mal. Aber ich kann es gerade nicht implementieren.


Momentan poppt aber lediglich die Fehlermeldung in Funktion zwei [also hier im Code ganz oben] auf,
danach die ExceptShowmessage in Function zwei
und das Programm bricht ab. Mehr passiert nicht.

Delphi-Quellcode:

implementation

{$R *.DFM}

function DieZweiteFUNC(A_egal: string): boolean;
var zweite: Integer;
begin
Form1.Top := 0;

  try
    begin
      zweite := 8 div Form1.Top; // irgendein Wert durch -> NULL 0, damit es abbricht
      ShowMessage(inttostr(zweite));
    end
  except
    ShowMessage('zweite KLAPPT NIX');
  end;
end;

function checkit(Bla: string; Blubb: string): boolean;
var erste: integer;
begin
  try
    begin
      DieZweiteFUNC('rufe zweite');
    end
  except
    ShowMessage('JA NÖÖÖÖÖÖÖ erste nich');
  end;
end; // END FUNCTION




procedure TForm1.Button1Click(Sender: TObject);
var SOURCE: integer;
begin
  try
    begin
      checkit('A', 'C');
    end
  except
    ShowMessage('JA NÖÖÖÖÖÖÖ Hat nicht funktioniert.');
  end;
end; // END FUNC

end.

Danke.[/Spoiler]

[Mavarik]

Abgesehen davon, das try except kein begin end braucht...

Ein except fängt die Exception ab... Dann läuft das Programm weiter (nur in der IDE kommt die Exception durch)

Also Variable setzen oder mit einem Raise wieder eine exception auslösen...

Mavarik

[Sir Rufo]

Mit deinem

Delphi-Quellcode:

try ... except

fängst du die Fehlermeldungen ab un danach gibt es keinen Fehler mehr.

Darum ist das ja auch totaler Humbug.

Delphi-Quellcode:

implementation

{$R *.DFM}

function DieZweiteFUNC(A_egal: string): boolean;
begin
  raise Exception.Create( 'simulierter Fehler' );
  ShowMessage( A_egal ); // wird nicht ausgeführt 
end;

function checkit(Bla: string; Blubb: string): boolean;
begin
  DieZweiteFUNC('rufe zweite');
  ShowMessage( Bla + Blubb ); // wird nicht ausgeführt
end; // END FUNCTION

procedure TForm1.Button1Click(Sender: TObject);
begin
  checkit('A', 'C');
  ShowMessage( 'Alles schick' ); // wird nicht ausgeführt 
end; // END FUNC

Nach dem ButtonClick kommt eine Dialogbox mit der Fehlermeldung "simulierter Fehler"

[himitsu]

Wenn man Exceptions falsch behandelt, dann soll man sich nicht wundern.
Vorallem nicht mit MessageBoxen.

Exteptions rauschen immer bis dahin durch, wo sie abgefangen und nicht erneut ausgelöst werden.

Und zum Probieren braucht man keine Funktionen.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var SOURCE, erste, zweite: Integer;
begin
  try
    try
      Self.Top := 0;
      try
        //zweite := 8 div Self.Top; // irgendein Wert durch -> NULL 0, damit es abbricht
        raise EDivByZero.Create('*peng*');
        ShowMessage('Test');
      except
        ShowMessage('zweite KLAPPT NIX');
        raise;
      end;
    except
      on E: Exception do begin
        //ShowMessage('JA NÖÖÖÖÖÖÖ erste nich');
        E.Message := 'JA NÖÖÖÖÖÖÖ erste nich' + sLineBreak + E.Message;
        raise;
      end;
    end;
  except
    on E: Exception do begin
      //ShowMessage('JA NÖÖÖÖÖÖÖ Hat nicht funktioniert.');
      ShowMessage('JA NÖÖÖÖÖÖÖ Hat nicht funktioniert.' + sLineBreak + E.Message);
    end;
  end;
end;

[BMI]

Wahh ;D
nee, ich will doch gar nich ohne Excep, äh, alles in einem Button unterbringen.

Hab mich vielleicht nur falsch ausgedrückt, weil ich nich so firn bin in Delphi (und das gerade ganz herb bereue, ... ehrlich ..)

Ich habe verschiedene, unabhängige Funktionen - und diese möchte ich aus verschiedenen Prozeduren und anderen Funktionen heraus aufrufen können, möchte aber über den Erfolg informiert werden.

d.h. wenn die ProgrammBefehle in der zweiten Function aufgrund eines Fehlers nicht ausgeführt werden können, soll eben eine Rückmeldung bis in die Buttonprozedur erfolgen.

In function 1 und 2 erfolgen natürlich noch andere Befehle, als nur das Dividieren, Message-Ausgeben und Aufrufen anderer "Sub-Funktionen".

Ich möchte nur sicherstellen, daß die ganze Kaskade abgerbrochen wird und auch in der Buttonprocedure dann danach nicht munter weitergearbeitet wird, wenn in Function 2 oder 1 etwas fehlschlägt.

function1 bereitet Daten evtl. auf/vor, function2 führt Dateioperationen durch. So in der Art.

Hoffe, das wird klarer. Ich hatte die Funjtionen oben ja nur wegen der Übersichtlichkeit ihrer weiteren Befehle bereaubt.

Danke aber schon mal. LG

[himitsu]

Zitat:

Zitat von BMI (Beitrag 1291190)

Ich möchte nur sicherstellen, daß die ganze Kaskade abgerbrochen wird und auch in der Buttonprocedure dann danach nicht munter weitergearbeitet wird, wenn in Function 2 oder 1 etwas fehlschlägt.

Dann darfst du auch nicht soeinen "Mist" bauen, die Exceptions sinnlos abfangen, dafür unpassende und nichtssagende Dialoge anzeigen und die Exceptions nichtmal weiterzureichen.

Und das mit dem zusammengefassten Code, bezog sich nur auf's Testen und das Rumspielen mit den Exceptions.
Denn so ist alles zusammen und man sieht auch viel besser, wie wo die Bearbeitung lang geht.

also siehe Sir Rufo und hier sein code zusammengefasst

Delphi-Quellcode:

raise Exception.Create( 'simulierter Fehler' );
ShowMessage( A_egal ); // wird nicht ausgeführt
ShowMessage( Bla + Blubb ); // wird nicht ausgeführt
ShowMessage( 'Alles schick' ); // wird nicht ausgeführt

[Dalai]

Zitat:

Zitat von BMI (Beitrag 1291190)

Ich habe verschiedene, unabhängige Funktionen - und diese möchte ich aus verschiedenen Prozeduren und anderen Funktionen heraus aufrufen können, möchte aber über den Erfolg informiert werden.

Dafür hast du ja die Rückgabewerte der Funktionen, nur auswerten tust du sie im Beispiel nicht. Exceptions rauschen von unten nach oben durch, bis zu der Ebene, wo sie behandelt werden. Werden sie gar nicht (im eigenen Code) behandelt, tut das der allgemeine Exception-Handler von TApplication (?) und sollte der aus irgendwelchen Gründen nicht anschlagen, kommt der vom Betriebssystem zum Tragen. Und dann gibt's noch die Fälle, in denen gar nichts anschlägt, aber die lass ich jetzt unter den Tisch fallen *plumps*.

Ach, übrigens sollte man Exceptions nicht zur Code-Steuerung benutzen. Exceptions sind Ausnahmen/Ausnahmesituationen, in denen etwas (ganz) schlimm fehlschlägt, und sollten als solche auch behandelt werden. Das nur zu "Vorbeugung", bevor du auf derartige Ideen kommst.

MfG Dalai

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1291193)

kommt der vom Betriebssystem zum Tragen

Das stimmt, aber dem sollte man besser keine Exception geben.

Was dann passiert, sieht man an Konolenanwendungen und an vielen Nicht-RTL-Threads (ohne TThread).
Denn Windows reagiert da sehr nett und schießt die komplette Anwendung ab.

Darum hat auch TThread.Execute nochmal ein Try-Except drumrum, wobei diese Exceptions leider nicht automatisch angezeigt werden.
Und auch die neuen Konsolenanwendungen in aktuelleren Delphis haben in der Codevorlage (der DPR) nun endlich ein Try-Except mit drin.

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1291194)

Das stimmt, aber dem sollte man besser keine Exception geben.

Jein. Man sollte Exceptions natürlich selbst und möglichst früh behandeln. Aber es gibt Situationen, in denen es gar nicht anders geht, weil irgendeine bekloppte Anwendung die Exception-Handler umgebogen hat, so dass die eigenen gar nicht anspringen, wie ich erst vergangenen Monat mitbekommen und debuggen "durfte".

Zitat:

Was dann passiert, sieht man an Konolenanwendungen und an vielen Nicht-RTL-Threads (ohne TThread).
Denn Windows reagiert da sehr nett und schießt die komplette Anwendung ab.

Und gibt eine entsprechende Meldung darüber ab - immer noch besser als eine ohne Kommentar komplett von selbst im Nirvana verschwindende Anwendung, bei der man die Ursache für den Crash nicht ermitteln kann (siehe oben bzw. verlinktes Thema).

MfG Dalai

[BMI]

Hier neu:

Also ich möchte nochmal fragen, weil ich nicht im ersten Thread den Code verändfern wollte, da sonst die Quotes nicht mehr stimmig sind = ich hoffe, das ist eine gute Entscheidung.:pale:

Ich habe auch versucht, Eure Ratschläge umzusetzen (soweit ich das verstanden habe - hoffentlich richtig)

Was ich nämlich brauche:

Delphi-Quellcode:

Function Umbenennen_vorbereiten()
begin
    BewegeDatei(Move/Überschreiben())
end;

Button.click()
begin
    if FileExists(neuerOrt) then
          Umbenennen_vorbereiten() // über Umweg mit AuswahlDialog
else
   BewegeDatei() // direkt
end

Die function BewegeDatei soll also so oder so aufgerufen werden [sie enthält u.A. moveFile() bzw. moveFileEx()=^Überschreiben, was je nach gesetzter Checkbox ausgeführt wird - entweder kann sie direkt sufgerufen werden (Datei existiert nicht) oder es wird erst in der Funktion Umbenennen_vorbereiten ein Dialog erstellt und abgefragt und von dort die Funktion BewegeDatei aufgerufen.

Delphi-Quellcode:

 // /////// ACHTUNG: GEÄNDERTE, aktuelle, reale FUNCTION NAMEN !
implementation

{$R *.DFM}

function BewegeDatei(Ort_A: string; Ort_B): boolean; // ehemals "Zweite Function"

begin
  try // wohl das einzige, try, was bleiben darf ?!!
      moveFile(Ort_A, Ort_B) //     ShowMessage('Verschieben klappt');
  except
    ShowMessage('Meldung aus zweiterFunc: Verschieben klappt irgendwie nicht');
  end;
end; // End Function BEWEGEN


function Umbenennen_vorbereiten(Bla: string; Blubb: string):  boolean; // ehemals "erste Funcition"
var erste: integer;
begin
//  try
    ExtensionExtrahieren(OrtB);
    NeuerDateiName := OrtB + inc(Zahl) + Extension; // Namensfindung abgekürzt!

       if NOT BewegeDatei(OrtA, NeuerDateiName ) then
//  except
    ShowMessage('Hier gibt s ein echtes Problem: Datei läßt sich nicht bewegen.');
  end;
end; // END FUNCTION Umbenennen


procedure TForm1.Button1Click(Sender: TObject); ///////// BUTTON
var SOURCE: integer;
begin
//try
   if  Bewege('C:\Datenlager.txt', ''E:\Datenlager.txt'') then
     Dateiliste.delete(MaximalwertDerListe-1)  //als erledigt von Liste streichen
else
//  except hier gibt es dann ein Problem // ehemals:
 ShowMessage('Es hat gar nix funktioniert');

  end;
end; // END BUTTON

end.

Mhh, kann das so ^^ klappen?

Danke.