Office: (Office 2003) Error handling

Gerade beim Einsatz des GEH sehe ich bei Klassen einen riesigen Vorteil.

Ein paar Annahmen:
In den Prozeduren existieren nur eine übliche VBA-Fehlerbehandlung, wenn auf eine spezielle Ausnahme reagiert werden soll.
Das würde bei mir bewirken, dass faste alle meiner Klasse überhaupt keine Fehlerbehandlung enthalten müssten. (Ausnahme wäre jene Klasse, die auf einen Verbindungsabbruch zur DB reagieren soll und bei einem Fehler einen neuen Verbindungsversuch starten soll.)

Setze ich den GEH ein, habe ich den Vorteil, dass mir eine auswertbare Fehlermeldung entsteht, aus der ich für eine möglicherweise notwendige Bugbehebung nachvollziehen kann, wo der Fehler auftrat bzw. ob überhaupt die Anwendung am Fehler schuld ist.
Setze ich den GEH nicht ein, funktionieren die Klassen trotzdem, es gibt nur die ausführliche Information über die Entstehungsgeschichte des Fehlers nicht.

Ich nehme den GEH also wörtlich und betrachte ihn als Lösung für die globale Ausnahmenbehandlung und nicht für irgendwelche Sonderbehandlung von Klassen bzw. Prozeduren.

Dein API-Ansatz ist keineswegs unabhängig von einer Fehlerbehandlung, weil du damit Fehler aufheben muss, um überhaupt eine negative Erfolgsmeldung zurückgeben zu können. Wenn du nämlich einen unbehandelten Fehler hast, kommst du gar nicht mehr zu Prüfung, ob der Rückgabewert der Funktion passt.

mfg
Josef

 

Hallo?!
Nur mal von einem Außenstehenden zwischendurch gefragt: Wann ist der Thread zuende? *wink.gif*
Das kann doch nicht sein, dass man allmählich nicht zu einem verwertbaren Resumee kommt, das zusammengefasst ein paar Essentials der Fehlerbehandlung unter VBA enthielte? Ich fände das im Interesse all jener, die hier anfangs mitlasen, aber inzwischen die Segel gestrichen haben (wie mich), ganz sinnvoll.
Ganz im Ernst: In solcher Ausführlichkeit habe ich VB-Fehlerbehandlung noch nirgendwo bis ins Detail ausgeleuchtet gesehen, so dass es wirklich schade wäre, wenn man aus der Diskussion nicht ein paar grundlegende Handreichungen für die Nachwelt liefern könnte.
Im Moment steht es aber noch 8:9, oder so?

Ciao, Sascha

 

Siehst Du alles so absolut exakt richtig.

Nur das was eine Klasse wirklich beheben soll immer und in jedem Fall, wie z.B. die Klasse für den Verbindungsaufbau die bei einem Verbindungsabbruch selbstständig versucht die Verbindung wieder her zu stellen, in der Klasse behoben werden soll /muss weil es eine Aufgabe der Klasse ist bekommt noch einen klassischen VBA-Error-Handler ... alles andere bekommt ein On Error Resume Next spendiert, damit es auch bei Klassen-Nutzern ohne GEH (bzw. vbWatchdog wie die neue Version nun heisst) abläuft.

Du musst dann aber allerdings für solche Fälle - eben Nutzung ohne vbWatchdog - selber regeln wie die Klasse aus Programmlogik-Sicht weiter verfahren soll wenn in ihrem Inneren ein Fehler auftritt.

Daher ja die Grundüberlegung mit dem API-Style. *wink.gif*

Ist natürlich richtig ... in jeder Prozedur nach API-Style muss ein "On Error Resume Next" gefolgt von "Err.Clear" rein zu Beginn.

Aber das ansonsten so große Problem von On Error Resume Next ... man bekommt nichts von den Fehlern mit ist mit dem API-Style und dem vbWatchdog absolut obsolet.

Der globale Error-Handler wird auch bei On Error Resume Next angesprungen und somit ist eine Protokollierung gewährleistet und dann der Fehler-Rückgabe der API-Style Prozedur entscheidet die aufrufende Sub was sie nun macht ... Abbruch oder Verzweigung in einen anderen Ablaufplan oder what ever.

Fehler komplett zu ignorieren, bzw. zu vergessen geht gar nicht mehr. ^^

Es läuft nun anders ab ... man muss es separat und ausdrücklich programmieren wenn Fehler ignoriert werden sollen.

Ein On Error Resume Next ist nicht mehr die völlige Ignoration von Fehlern, sondern einfach nur die Anweisung für den vbWatchdog: Bitte protokollieren und danach mit nächster Zeiler weiter machen.

Und ist der vbWatchdog mal nicht anwesend (z.B. fremder Klassen-/Modul-Nutzer), braucht man keine einzige Zeile Code umzubauen da der Programmablauf absolut wasserfest abgesichert ist.

So zumindest mal meine Gedanken.

Habe heute von Wayne Phillips die neueste Beta bekommen und bin gerade dabei diese in einer Test-DB auszutesten ob das auch alles in der Praxis so läuft wie ich hier rum theorisiere. *g*

EDIT:

Ich habe nicht mitgezählt, würde mich aber sehr verwundern wenn ich so nahe an Josef rangekommen wäre. *g*

Da Josef ja auch bekanntermaßen der Autor von Fachartikeln ist, überlasse ich ihm natürlich gerne den Vortritt für die Verfassung einer kleinen Anleitung für die Nachwelt. Vor allem auch unter dem Aspekt das man meine Rhetorik nur am Abend lesen kann (danke @ Micha_Du ^^).

Gruß

Rainer

 

Eines kann ich zusammenfassen, bei dem ich mir relativ sicher bin, dass auch Rainer meiner Ansicht ist:
Erstelle in Prozeduren, die nicht die äußerste Aufrufhierarchie darstellen, lieber keine Fehlerbehandlung, bevor du eine Fehlerbehandlung einbaust, die nur den Fehler meldet, dann aber die aufrufende Prozedur so weitermachen lässt, als wäre nichts gewesen.
Erlaubte Ausnahmen:

• Ein Fehler soll bewusst ignoriert werden.
• Eine Prozedur ist für den Einsatz im Select-Teil einer Abfrage gedacht ... dort kann es nämlich etwas lästig, wenn je Datensatz die Fehlermeldung bestätigen müsste.

Bezüglich Klassendesign wird es vermutlich auch in den nächsten 357 Beiträgen keine Übereinstimmung geben. *biggrin.gif* *biggrin.gif* *biggrin.gif* *biggrin.gif* *biggrin.gif*

 

Ich sponsor euch beiden einen Kasten Bier, den macht ihr dann mal zusammen leer und teilt uns danach das Ergebnis mit *wink.gif*

 

Und was soll Josef trinken?

Absolut wahrscheinlich. *g*

Gruß

Rainer

 

Ich empfehle entweder einen guten Roten aus dem südlichen Burgenland (vielleicht einen Uhudler)? Oder einen Barack (nee, keinen Obama sondern Palinka). *wink.gif*

 

woher soll ich denn wissen, dass er kein Bier trinkt?

Sollte ich dem Gespräch beiwohnen, nehme ich 2 Kästen Bitburger mit... Windows kann mit 32 Bit schon einiges, ich dann bestimmt auch o)

 

Das weiss ich auch nicht ... aber ich weiss was und wieviel ich trinke. *g*

Gruß

Rainer

 

\@ All

Habe heute eine sehr interessante Information von Wayne Phillips bezüglich der Änderungen in der neuen Version des SimplyVBA GlobalErrorHandlers (bzw. neue Version heisst dann vbWatchdog) bekommen und auch an der neuesten Beta gleich austesten können:

Die Einstellung in ErrEx.State nach einem Fehler mit OnErrorEnd weiter zu machen, hat nun folgenden Unterschied zu dem normalen Code-Abbruch in VBA bei unbehandelten Fehlern:

- globale und modulweite Variablen behalten Ihre Inhalte, sowohl in normaler als auch in Runtime-Umgebung (das war aber schon vorher der Fall)

- in der Runtime-Umgebung wirkt sich die Einstellung aus als wenn die oberste aufrufende Prozedur ganz normal am Ausstiegspunkt (End Sub/Exit Sub) verlassen worden wäre ... also kein automatisches Schliessen der Runtime mehr (das ist die Neuerung)

Gruß

Rainer