TRY...EXCEPT-Fehler

[simlei]

Ich hatte wieder etwas mahcen wollen wo gerne Fehlerchen auftreten. früher hatte ich einmal zum abfangen folgende Konstruktion verwendet:

Delphi-Quellcode:

try
    ShowMessage('BLUB');
except
    on E: Exception do ErrorDialog(E.Message, E.HelpContext);
end;

aber nicht einmal diese Beispiel, was so auch in der Delphi-Hilfe angegeben ist:

Zitat:

An exception handler can specify an identifier before the name of the exception class. This declares the identifier to represent the exception object during execution of the statement that follows on...do. The scope of the identifier is limited to that statement. For example,

try
...
except
on E: Exception do ErrorDialog(E.Message, E.HelpContext);
end;

funktioniert, es kommt: "Class Type required". Was zu tun?

[DeddyH]

Die Unit SysUtils ist eingebunden?

[simlei]

Sorry - habs. Was es nich alles gibt...

Ich hatte die Uses OutlookXP mit eingebunden. da scheint es auch eine Exception zu geben (OutlookXP.Exception, IDispatch). Diese wird hier standardmäßig genommen, und es geht nicht (man muss die SysUtil.Exception nehmen).

Edit: Ja ist eingebunden ist ja nun geklärt.

[Christian Seehase]

Moin simlei,

es würde übrigens schon helfen die Reihenfolge, in der die beiden betroffenen Units unter uses stehen zu vertauschen.

[Dezipaitor]

Zitat von Christian Seehase:

Moin simlei,

es würde übrigens schon helfen die Reihenfolge, in der die beiden betroffenen Units unter uses stehen zu vertauschen.

Ja das dachte ich auch mal. Nachdem dann eine Weile vergangen ist, und man das Problem vergessen hat, tritt es urplötzlich wieder auf - und das noch leicht verändert.
Wenn man mal auf so ein Problem trifft, dann sollte man immer Unitnamen vor die entsprechenden Bezeichner setzen (System.Delete(xy..)). Also wirklich nur dort wo es notwendig ist.
Bei JediAPI ist das notwendig.
---
Ich finde übrigens die Informationen in Exceptions viel zu wenig. Warum wurde die Exceptionklasse nicht mit mehr Eigenschaften ausgestopft, die man dann im Create füllen muss?
Nach meiner Meinung gehört dazu :

• Methodenname oder Funktionsname, bzw Callstack.
• Klassenname (wenn vorhanden)
• Quelldatei
• Quellzeile
• GetLastError (wenn gewünscht) mit Fehlernummer und Fehlerbeschreibung
• Automatische Formatierung

Ich habe mir das schon lange so angewöhnt :

Delphi-Quellcode:

raise ESMWinCallFailedException.CreateFmtEx(
'Call to EqualSid failed. %s',  //Beschreibung
'EqualSid', //Methodenname
ClassName, //Klassenname
'USM_SID.pas',  //Quelldatei
0, //aktuelle Zeile
true, //GetLastError auswerten?
[sString]); //Formatierungen

Leider sind zwei Dinge aktuell nicht ohne weiteres zu lösen:

• Quellzeile : Die Zeilen ändern sich ständig und ohne einen Präprozessor kann man hier Momentan nichts machen.
• Methodenname : Hier wird zwar angegeben, dass raise in dieser Methode aufgerufen wurde, jedoch könnte die Exception auch durch
  eine andere Methode erzeugt worden sein, die eben diese Methode aufgerufen hat. Ein Callstack wäre eine prima Aufrufrückverfolgung.

Nur wie machen?

[squetk]

Zitat von Dezipaitor:

Ich finde übrigens die Informationen in Exceptions viel zu wenig. Warum wurde die Exceptionklasse nicht mit mehr Eigenschaften ausgestopft, die man dann im Create füllen muss?
Nach meiner Meinung gehört dazu :

• Methodenname oder Funktionsname, bzw Callstack.
• Klassenname (wenn vorhanden)
• Quelldatei
• Quellzeile
• GetLastError (wenn gewünscht) mit Fehlernummer und Fehlerbeschreibung
• Automatische Formatierung

Ich finde die JEDI's haben mit dem ExceptDlg da eine Lösung, die fast alle Infos - die oben angesprochen sind - preisgibt. Den Dialog kann man ja problemlos ans Corporate Design anpassen und fügt sich dann nahtlos ins Programm ein.

[jbg]

Zitat von Dezipaitor:

Warum wurde die Exceptionklasse nicht mit mehr Eigenschaften ausgestopft

Weil Delphi (Win32) nicht in einer virtuellen Maschine läuft und auch keine Scriptsprache ist

Übrigens den Klassen-, Methoden- und Dateinamen könntest du über die JclDebug Funktionen bekommen.