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?