NotifyWindow, dynamisches Fenster in nur einer Prozedur inklusive Events und AA

[FarAndBeyond]

Zitat:

Das mit dem Errorlog ist bestimmt gut gemeint, aber nicht gut gemacht. Man weiß, dass etwas schief gelaufen ist, aber was?

Ja, das stimmt, aber der ErrorLog ist eigentlich auch nur für mich und ich brauche ihn in erster Linie während der Programmerstellung. Nach Fertigstellung sehe ich normalerweise nie wieder was von ihm...
Ich weiß damit genau in welcher Unit und in welcher Prozedur das Problem entsteht. Auf der anderen Seite ist fraglich ob ein Nutzer mit den Exception-Meldungen vom OS besser klarkommt. Nichtmal ein ASM-Programmierer kann mir detailierte Informationen geben über "Read von Adresse blablabla hat nicht funktioniert.." und genauso sehen oft die OS-Meldungen aus. Um detailierte Informationen für einen Nutzer ausgeben zu können, müßte man sehr viel öfter TryExceptEnd benutzen und dann genau beschreiben was das Programm gerade macht oder versucht zu machen. Ich finde das ist nicht nötig und für meine eigenen Sachen sowieso nicht. Ein Nutzer wird sich sowieso an den Programmierer oder die Softwarefirma wenden und mit der Problembeschreibung und dem ErrorLog bleiben für mich keine Fragen offen. Aber das hier ist nur ein Beispiel wie man soetwas machen kann, es gibt zahlreiche Möglichkeiten und ich hab' ja nie behauptet, dass diese hier die Beste sei. Niemand muß das so nachmachen. Für mich ist das super, da der ErrorLog kurz ist und ich doch genau weiß wo ich suchen muß. Bei sehr langen Prozeduren kann man ja mehrere Unterteilungen machen.

Zitat:

Exit; // kann ersatzlos gestrichen werden, wenn nichts mehr danach kommt

Ja, allerdings hab' ich auch schon bemerkt, dass bei der Verwendung von z.B. OnClose ein Exit unverzichtbar ist sonst bleiben einige MB im Taskmanager hängen.
Ich dachte ich geh' mal auf Nummer sicher...

Zitat:

FreeAndNil wirft keine Exception. Davon abgesehen ist es eine ziemlich dumme Idee eine Exception zu verschlucken.

Ja, FreeAndNil prüft erst, aber da ich nicht weiß ob das wirklich in jedem erdenklichen Fall zu keiner Exception führt, dachte ich mir ich geh' nach dem Ausschlußprinzip vor.
Sicher ist sicher. Was soll ich mit einer Exception, die möglicherweise geworfen wird aufgrund einer Stringlist, die nicht freigegeben werden kann. Oder was soll ein Nutzer mit so einer Exception anfangen. Wo soll da der Nutzen sein. Ich gebe etwas frei und sollte das nicht funktionieren, dann muß eben später das OS aufräumen...
Eine Meldung will ich da gar nicht sehen und ein Nutzer kann da auch nichts machen wenn es dabei Probleme geben sollte. Natürlich könnte man fragen wie oft klappt so eine Freigabe nicht, aber sicher ist sicher.

Ich hab' selbst mit zu viel Fremdsoftware nervige Erfahrungen gemacht wenn es um überflüssige Errormeldungen und OS-Exceptions ging. Ich sehe da keinen Sinn drin.
Ich denke eine Meldung ist nur dann sinnvoll, wenn der Nutzer auch wirklich was damit anfangen kann bzw. etwas verändern kann.
Wenn ich dem Nutzer eine Meldung z.B. per NotifyWindow.Show(...,...); zukommen lassen möchte, dann mache ich das ausführlich, verständlich und vielleicht in Deutsch und Englisch und wozu brauche ich dann noch die OS-Exception? Die wird sicher nicht ausführlicher oder gar präziser sein können.

Die meisten Nutzer, die keine Programmierer sind werden sich von zu viel "Belästigung" nur gestört fühlen oder das Vertrauen in die Software verlieren. Zumal sehr schnell Themebereiche übersprungen werden und dann hört man plötzlich: "Die Software ist nicht sicher." oder etwas in der Richtung und das eine hat oft mit dem anderen nichts zu tun.

Zitat:

FileExists('ErrorLog.txt') Ohne Pfadangabe ist das russisches Roulette.

Bis jetzt nimmt sich mein Programm immer die richtige Textdatei wenn ich keinen Pfad angebe...
Normalerweise benutze ich

Delphi-Quellcode:

ApplicationPath:= ExtractFilePath(Application.ExeName);

.

[Sir Rufo]

Die Exception mit "Access-Violation Read From Address" ist doch relativ klar.

Du versuchst gerade auf eine

Delphi-Quellcode:

nil

Instanz zuzugreifen oder auf eine bereits entsorgte Instanz (dangling pointer).

Ja es gibt so erst einmal keinen Stacktrace (den kann man mit MadExcept aber erhalten).

Ein stumpfes Unterdrücken der Exceptions erschwert aber die Fehlersuche ungemein (gibt dazu einige Beispiele hier im Forum). Es tut nicht und ich weiß nicht warum und habe noch nicht einmal einen Anhaltspunkt.

Viel sinnvoller als das Unterdrücken ist das aktive Werfen von Exceptions z.B. beim Aufruf von Methoden, wo zunächst geprüft wird, ob die Argumente auch schlüssig sind.

Wenn nicht, wirft man eine Exception

Delphi-Quellcode:

EArgumentException

oder

Delphi-Quellcode:

EArgumentNilException

und gibt den Namen des Arguments mit an. Schon werden die Exceptions (wenn diese kommen) wesentlich informativer und leiten einen sehr schnell zur Ursache des Übels. ;)

[FarAndBeyond]

Zitat:

Ja es gibt so erst einmal keinen Stacktrace (den kann man mit MadExcept aber erhalten).

Ja, MadExcept hab' ich schon öfter mal gelesen... kann auch gleich 'nen Screenshot machen...

Zitat:

Ein stumpfes Unterdrücken der Exceptions erschwert aber die Fehlersuche ungemein (gibt dazu einige Beispiele hier im Forum). Es tut nicht und ich weiß nicht warum und habe noch nicht einmal einen Anhaltspunkt.

Ja, da hast du wohl Recht... da kann man lange grübeln..

EArgumentException und EArgumentNilException kannte ich noch nicht.. muß ich mal ausprobieren.

Wenn ich mal ein sehr viel größeres Programm schreibe, dann hab' ich ja vielleicht auch mal Bedarf auf spezielle Exception Gruppen oder Klassen eingehen zu können oder zu müssen.
Z.B. EMathError oder EOutOfMemory oder ERangeError oder EStackOverflow usw... um dann je nach auftreten etwas spezielles zu tun.
Dann wird sich das Exception-Handling sowieso total verändern.