Office: (Office 2003) Error handling

Weil er vielleicht sonst gar nicht erfährt, dass er falsche Parameter an deine Prozedur übergeben hat.
Entweder du zwingst den Nutzer dazu auf das Ereignis zu reagieren oder du zwingst ihn dazu die If-Prüfung auf mögliche Fehler im Ablaufcode einzubauen.
(Ich gehe davon aus, dass du nicht generell die Festlegung treffen willst, das automatisch On Error resume next gilt, wenn nicht explizit auf Fehler geprüft wird und der Fehler über den GEH nicht behoben werden konnte.)

Ich behaupte nur, dass ein Fehler immer ein Fehler bleiben und nicht zum Ablaufcode werden soll.
Wenn du in einer Klasse nirgends eine Fehlerbehandlung einbaust, hast du meiner Ansicht nach ein besseres Klassendesign, als wenn du unerwartete Ausnahmen einfach übergehst und nur Codierte Werte zurück gibst, die ich erst wieder im Ablaufcode geprüft werden müssen, um zu entscheiden ob abgebrochen werden soll.

Damit man aber weiß, ob man in den Error-Elementen nachsehen muss, muss man dafür im Programmcode überall die Prüfungen einbauen. Wo ist da bitte die Trennung von der Fehlerbehandlung? Oder endet bei dir die Fehlerbehandlung mit der Aufhebung des Fehlers? Bei mir endet sie erst mit der Beseitigung des Fehlers bzw. Entscheidung, dass der Fehler keine Rolle spielt - oder eben mit dem kompletten Abbruch des Aufrufs.

Bezüglich "Back-Box-Prinzip" kann ich dich nur bitten, ein wenig in den Entwurfsrichtlinien zum Entwickeln von Klassenbibliotheken der MSDN zu schmökern. Vielleicht wird dann auch klarer, warum ich von deinem Konzeptvorschlag nicht besonders begeistert bin. Dass wir beide eine etwas andere Vorstellung von Klassengestaltung haben, wissen wir ja zum Glück schon länger, daher ist meine Vermutung, dass die Verständnisschwierigkeiten daraus resultieren, wie wir uns die Arbeit mit Klassen vorstellen. *biggrin.gif*

mfg
Josef

 

Okay gut ... so gesehen hast Du auch wiederum Recht.

Aber das wäre mit ein paar kleinen Änderungen erledigt:

Code:

Und damit wäre die Auslösung eines Ausnahmefalles auch in der Klasse eingebaut.

Ohja ... ^^

Gruß

Rainer

 

So wie in deinem letzten Beispiel kann ich mir das schon viel besser vorstellen.
Damit funktioniert dann aber diese Variante nicht mehr:
Code:

.. bzw. du musst eine extra Ereignisbehandlung erstellen, die im Fall dieser Fehlerprüfung, das Err.Raise verhindert.


Ich würde diesen Aufwand gar nicht betreiben, wenn ich den GEH einsetze, sondern nur dort eine Fehlerbehandlung einbauen wo ich gezielt in der Prozedur bestimmte Ausnahmen behandeln will.
Im Prinzip so etwas ähnliches (nur etwas schöner *biggrin.gif*) wie:
Klasse:
Code:

mfg
Josef

 

Genau richtig, die muss dann wie in jedem allgemeinen Modul üblich Fehler aus der Klasse dann über den Error-Handler abfangen. Geht ja auch gar nicht anders ... würde bei Deiner Vorgehensweise auch nicht anders gehen.

Einzig und alleine könnte man noch eine Property Let einbauen die zusätzlich zu dem Rückwurf vom RaiseEvent prüft ob ein Err.Raise ausgelöst werden sollte.

Also im Prinzip so:

Code:

Damit könnte der nutzer für sich selber entscheiden ob er in einem allgemeinen Modul bei Fehler ein Err.Raise aus der Klasse haben will oder ob nicht.

Ah oki ... jetzt habe ich es wieso Du meine Idee/Vorstellung mit dem Thema API-Style Funktionen in Kombination mit dem GEH nicht verstehst. ^^

Du brauchst kein On Error Goto Err_Handler in einer Prozedur um auf Fehler mit Fehlerbehebung zu reagieren.

Hier ein Beispiel wie es geht mit dem GEH (aber bitte ... nur Luftcode, ungetestet und auch nur als Grobprinzip zu verstehen):

Code:

Mehr ist nicht nötig um Fehler aus diesen beiden Propertys individuell zu beheben.

Mit dem GEH würde das Prinzip so aussehen, z.B. im Modul mdlFehler:

Code:

Bis auf die Setzung des Fehler-Bookmarks braucht man keine einzige Zeile Code um Fehler individuell zu behandeln mit dem SimplyVBA GEH.

Das ist ob natürlich noch ein völlig unausgereiftes Prinzip das ich erst nur teilweise getestet/probiert habe ... aber kann es theoretisch funktionieren. *wink.gif*

Deswehen sehe ich ja die exakte Trennung zwischen Ablauflogik und Fehlerbehandlung.

Kommt jetzt nur das Thema dazu wie meldet man nun der aufrufenden Sub das es einen Fehler gegeben hat.

Möglichkeit 1 (wie oben auch geschehen): ErrEx.State auf Abbruch der kompletten Aufruf-Kette setzen.

Möglichkeit 2 (mein Favorit): Über die Long-Rückgabe der Porzedur das der Programmlogik der aufrufenden Sub mit zu teilen ... gefällt mir einfach besser als die Holzhammer-Methode kompletter Abbruch (die aber wesentlich besser ist als einfach nur durchlaufen zu lassen ... keine Frage *wink.gif* )

Gruß

Rainer

 

Dann lässt du eben das OnError bei meinem Beispiel weg. Wenn ich in der Prozedur - und nur in dieser Prozedur - bestimmte Fehler abfangen will, werde ich immer in der Prozedur einen Code einbauen müssen, der das durchführt, oder?
Ich kann mir zumindest nicht vorstellen, wie ich das sonst gestalten sollte, damit es übersichtlich bleibt. (Beachte: ich schreibe hier von einer speziellen Fehlerbehandlung, die nur in einer bestimmten Prozedur und nur für bestimmte ausgewählte Fehler gilt.)

Dann wird eben aus:
Code:

folgendes:
Code:

Anm.: ich will in diesem Beispiel keine Standardwerte setzen und einen bestimmten Fehler aufheben, sondern eine bestimmte Fehlerbehandlung starten und dann je nach Ergebnis der Fehlerbehandlung (checkLoginDataError) entscheiden, ob ich abbrechen muss oder ob das Problem behoben wurde ich ich die Zeile, in der der Fehler ausgelöst wurde, noch einmal starten bzw. mit der nächsten Zeile fortfahren kann - falls der Fehler nicht behoben wurde, muss er wieder ausgelöst werden oder ErrEx so reagieren, dass das Springen auf die Bookmark-Stelle keine Auswirkung hat und der Fehler weiter nach oben gereicht wird (also die übergeordnete Aufrufebene an die Reihe kommt, falls dort vielleicht wieder so eine spezielle Fehlerbehandlung ist.

mfg
Josef

 

Müssen tust Du es nur wenn durch die Fehlerbehandlung Inhalte von Prozedur- oder Modul-Variablen neu gefüllt werden.

Wäre eigentlich ein tolles Feature wenn man im GEH durch den VariablenInspector nicht nur die Werte der Variablen auslesen, sondern auch gleich die Variablen neu befüllen könnte.

Siehe oben die Fehlerbehandlung die durch das Select Case Konstrukt entscheidet welche Fehlerbehebungsroutine gestartet werden soll.

Ich würde da nicht nur mehrfach verwendbare Fehlerbehandlungen reinsetzen, sondern eben auch umfangreichere Einzelfälle (1-2 Zeiler würde ich wohl nach wie vor direkt in der Prozedur schreiben wollen aus Faulheit ^^).

Ich denke das wird so gar nicht nötig sein.

Gerade wenn Du die Fehlerbehandlung eh in einer eigenen Routine verpackt hast, dann würde ich die nicht mehr aus dem Code der Prozedur anspringen sondern direkt aus dem GEH ... dann setzt die Fehlerbehandlung selber den ErrEx.State der nach Verlassen der globalen Fehlerbehandlung dann festlegt wie es in der Prozedur in der der Fehler auftrat weiter geht.

Im Gegensatz zum normalen Error-Handling in VBA kann ja ErrEx.State direkt innerhalb des globalen Error-Handlers neu gesetzt werden mit allen wünschenswerten Möglichkeiten.

Das einzige Thema wird die Übergabe von Variablen-Inhalten (s.o.) sein.

Noch eines ... da hatte ich zumindest zu Beginn einen Denkfehler ... die Bookmarks sind allgemeingültig. Das heisst Du kannst in Prozeduren in denen der gleiche Fehler auftreten kann immer das gleiche Bookmark verwenden. Der GEH springt nur die Bookmarks an die auch in der Prozedur die den Fehler ausgelöst hat definiert sind.

Gleichzeitig weiss der GEH aber innerhalb welcher Bookmark er sich befindet und so kann man für einen Fehler der innerhalb einer Funktion an zwei Stellen entstehen kann an Hand des Bookmarks in dem man sich gerade vom Code her gesehen befindet entscheiden was zu tun ist.

Daher finde ich es ja so klasse. *wink.gif*

Genau in diesem Falle wäre aber das Vorgehen innerhalb der Prozedur selber zu jonglieren nicht sinnvoll wenn man schon den GEH einsetzt.

Genau das würde ich komplett in die Abwicklung des globalen Error-Handlers legen. Gerade durch die Kombination von Bookmarks zum Rücksprung aber auch zur Auswertung an welcher Stelle innerhalb der Prozedur man sich befindet kann man im GEH den Rücksprung absolut exakt steuern.

Code:

Und in der globalen Fehlerbehandlung dann so:

Code:

Also quasi wird der Fehler im ersten Part der Prozedur ausgelöst dann wird zum BOOKMARK_ERROR_DIVBYZERO gesprungen. Wiederholt sich der Fehler während man sich im Bookmark BOOKMARK_ERROR_DIVBYZERO befindet wird dann die Prozedur beendet. Befindet man sich an ganz anderer stelle wird halt ein anderer Resume-Mode ausgelöst.

Klar, es wird sicherlich extrem komplizierte und verschatelte Sonderfälle geben bei denen die Nutzung des GEH's zu zu viel Verwirrung und Unübersichtlichkeit führt, aber das sind wohl die absoluten Ausnahmen und auch diese kann man ja perfekt im GEH berücksichtigen und entsprechend reagieren. *wink.gif*

Aber für wohl über 90% aller Fälle wie Du sie oben beschreibst brauchst Du die Variante mit der eigenen Bestimmung des Resume-Modes nicht mehr, sondern kommst perfekt mit den Bookmarks und der ErrEx.State Eigenschaft zu Recht.

Gruß

Rainer

 

Ich verstehe nicht, was die globale Fehlerbehandlung mit der Sonderbehandlung von Einzelfällen zu tun hat. Ich kann ja in einer allgemeinen Fehlerbehandlung niemals wissen, was ich in dem einen speziellen Sonderfall passieren soll.

Könntest du bitte folgendes Beispiel ergänzen, damit es etwas deutlicher wird.
Code:

Forderung:
Wenn in "berechneA" der Fehler auftritt, darf er nicht ignoriert werden, sondern muss in der aufrufenden Prozedur ebenso auftreten.
Wenn in "berechneB" der Fehler auftritt, soll -1 zurückgeben und der Fehler aufgehoben werden.

Mit einer VBA-Fehlerbehandlung könnte das so aussehen:
Code:

... ich würde als bei berechneB eine eigene Fehlerbehandlung einbauen und berechneA den GEH ohne irgendwelche Sondereinstellungen werkeln lassen. Und falls der GEH nicht eingesetzt wird, wird automatisch der Fehler in die aufrufende Prozedur weitergereicht - nur die Information über die Entstehungsgeschichte des Fehlers geht dann ohne GEH verloren.

Wie würdest du das mit lösen?

mfg
Josef

 

\@raist:
dein Posting #69 hab ich verstanden.
Die Perspektive eines Laufzeitfehlers fehlte mir, weil das in meinem Anwendungsfall nicht vorkommen kann (gewagte These *upps ) Mit deiner Erklärung im Hinterkopf weiß ich für zukünftige Fälle Bescheid *Smilie

 

Ich mache die Antwort mal als Prinzip und beachte dabei nicht, dass es für so einen Einzeiler eigentlich vllt wirklich keinen Sinn macht den GEH zu bemühen ... okay? *wink.gif*

Code:

Code:

Das wäre die eine Möglichkeit. Eine andere die ich sehe wäre die hier:

Code:

Code:

Und die dritte wäre die hier:

Code:

Code:

Denke das sind die 3 Wege im Groben mit dem Error-Handler. Für Deinen ganz speziellen Fall würde ich eh die Variante 3 wählen wollen ... bei allem was keine eigenes Error-Label besitzt und keine Bookmark für den Fehler wird prinzipiell an die aufrufende Sub zurück geworfen.

EDIT: Einfach weil es sowas schönes grundsätzlich Verlässliches hat. ^^

Hat die aufrufende Sub auch keine eigenes "On Error Goto/Resume ..." und auch keinen Bookmark für den Fehler müsste das theoretisch - weil noch nicht so ausgetestet - direkt bis in die oberste Ablaufebene zurück laufen, wenn nicht eine Eben dazwischen eine eigenes Error-Label oder ein Bookmark für den Fehler besitzt. Aber das wäre wie gesagt noch dezidiert zu prüfen.

Will aber nicht ausschliessen das mir bei näherer Betrachtung/testen des Objekt-Modells noch andere Möglichkeiten/Wege einfallen. *wink.gif*

Gruß

Rainer

 

\@ Micha_Du

Da stimme ich Dir zu. *g*

Puuuuuhhhhh ... dann kann ich mir ja doch nochmal überlegen ob ich wirklich so dringend meine Rhetorik ändern muss. *lach*

Gruß

Rainer

 

die Empfehlung, deine Posts erst abends zu lesen könnte auch schon ausreichen o))

 

Die erste Variante würde ich sicher nicht einsetzen, denn ein Select Case auf einen Prozedurnamen hat meiner Ansicht nach in einem globalen Errorhandler nichts zu suchen, weil der globale Errorhandler ja unabhängig von den Klassen sein sollte, die ihn verwenden, oder?
Es war doch sogar eine Forderung von dir, dass eine Klasse nicht von einem allgemeinen Errorhandler-Prozedur abhängig sein darf. *wink.gif*
Das schließt somit eine spezielle behandlung von Prozeduren in einer globalen Fehlerbehandlungsroutine aus.

Variante 2 und 3 kommen mir "sauberer" vor - falls ich den Ablauf richtige interpretierte.
Ich stelle mir ErrEx.SetBookmarkAsOnErrorGoto(Err.Number) = True so vor, dass an die jeweilige Bookmarkstelle in der Prozedur gesprungen wird, falls für die Fehlernummer so eine Stelle definiert wurde. Die Bookmarkkennung BOOKMARK_ERROR_DIVBYZERO ist gleichbedeutend mit der Fehlernummer (11), oder?

mfg
Josef

 

Völlig richtig.

Wenn Du die Konstante für den Bookmark so deklarierst, dann ja. Ich würde es so tun ... eben für jeden Fehler den ich speziell abfangen will eine Konstante festlegen die der Fehlernummer entspricht, also so:

Code:

Ich finde das das Geniale ... die Bookmarks sind schlicht Long-Werte und deren Definition ist nicht vorgegeben, sondern kann man völlig frei setzen.

Es geht auch ohne Konstante (für die Faulen die sich keine globalen Konstante-Sammlung für den GEH anlegen wollen ^^):

Code:

Da verstehst Du aber zwei Sachen völlig falsch ... oder ich verstehen was falsch (wohl der wahrscheinlichere Fall ^^).

1. Wieso wird der Error-Handler abhängig von der Klasse, einem Modul oder einer Prozedur wenn man ein Select Case auf einen Modulnamen/Prozedurnamen ausführt? Gar nicht ... gibt es die Klasse/das Modul oder die Prozedur gar nicht mehr im Projekt (z.B. nachträgliches Entfernen) passiert gar nix ... kein Compiler-Gemeckere einfach rein gar nichts. Das ist keine Abhängigkeit in meinen Augen, sondern dann einfach nur ein Fall in einem Select Case der nie zum Tragen kommen wird und gut.

2. Klassen sollen nicht vom globalen Error-Handler abhängig sein durch Anbindung an ihn ... das war meine Meinung, richtig. Aber das heisst doch nicht das der globalen Error-Handler nicht individuell auf Fehler aus dieser Klasse reagieren kann/soll, dadurch - s.o. - entsteht in meinen Augen keinerlei Abhängigkeit.

3. Ich finde die Lösung Klassenfehler über den GEH individuell je nach Projekt - natürlich zusätzlich zur Fehlerbehandlung in der Klasse selber - gesondert abfangen zu können und projekt spezifisch zu handeln mehr als genial.

Man programmiert die Klasse mit Fehlerrückmeldung über Ereigniss und eigener Ablauflogik was zu tun ist innerhalb der Klasse bei einem Fehler und that's it. Projektspezifisches Fehlerhandling wird dann ohne zwingende Abhängigkeiten zu erzeugen im GEH gehandelt ... besser jeht es nicht. *wink.gif*

Z.B. soll die Klasse wenn ein Fehler auftritt immer ein Err.Raise ausführen, aber ausser der Aufruf kommt aus Prozedur1 oder Prozedur66 und ist entweder Fehler 11 oder Fehler 91 ... in diesem Falle soll kein Err.Raise durchgeführt werden und die Fehlerbehandlung XYZ ausgeführt werden. Brauchst Du nicht mehr explizit zu programmieren sondern lässt die Klasse auf Err.Raise und wertest dann im GEH aus ob der obige Ausnahmefall aufgetreten ist und leitest bei ja die weiteren notwendigen Schritte ein.

Das sehe ich - mal wieder, wen wundert's ^^ - anders.

Es gibt Fehler die können ja in mehreren Prozeduren auftreten und benötigen allesamt die gleiche allgemeine Fehlerbehandlungsroutine aber Sie brauchen eine Variable aus der AUFRUFENDEN Prozedur, da die Fehlerbehandlung an Hand dessen Inhalt entscheidet what to do.

Du kannst das jetzt in jeder aufrufenden Prozedur einzeln programmieren oder Du löst es so:

Code:

Ganz ehrlich bevor ich in jeder aufrufenden Sub die Prüfung auf den Fehler mit Sprung in die Fehlerbehandlung rein programmiere, mache ich das lieber einmal im GEH und habe alle Ansprünge und alle Fälle die auf die Fehlerbehandlung zu greifen an einer einzigen Stelle gesammelt.

Der eine mag es halt wenn er jeden Sonderfall in der Prozedur selber erkennen kann und ich sammle lieber alle Aktionen einer Art und führe Sie von einer Stelle aus. Das erleichtert Wartung des Codes und Änderungen enorm ... weil es immer nur eine Stelle gibt an der man was ändern muss.

Z.B. im obigen Falle erweitert man die Behandlung um braucht dazu aber noch eine Variable aus der nächsten Aufruf-Ebene ... viel Spaß, dann kannst Du ohne die obige Vorgehensweise in alle Prozeduren die Aufrufe abändern/löschen/verschieben bis es wieder stimmt.

Mit der obigen Vorgehensweise baust Du einfach nur einen einzigen Code-Block ein (der den Var-Value der nächst höheren Ebene sich holt) und es stimmt für alle Prozeduren wieder.

Und vor allem ... die gesonderte Fehlerbehandlung ist auch oftmals projektspezifisch zu sehen. So hat man die gesonderte Fehlerbehandlung immer im produktiven Code stehen und müsste den dann einzeln abändern wenn man ihn in ein anderes Projekt übernimmt das in dem Fehlerfalle eine andere Behandlung benötigt ... löse ich das mit dem GEH importiere ich einfach das Modul/die Klasse mit den gesonderten Fehlerbehandlungen und ändere nur an einer einzigen Stelle den Code ab.

Sorry, aber ich finde das die optimale Kapselung von Fehlerbehandlungen zu Programmablauf ... sauberer, übersichtlicher und besser wartbarer geht es nicht mehr.

Wie gesagt, bei so einfachen Geschichten wie bei Fehler 11 einen Ersatzwert einzufügen, würde ich über die Bookmark-Lösung direkt im Code regeln.

Aber alles was eine eigene Routine zur Fehlerbehandlung anspringt, würde ich auf diese Weise auslagern.

Ist aber ja nur meine bescheidene Meinung und die ist natürlich nicht immer die Richtige. *wink.gif*

Gruß

Rainer

 

Der globale Errorhandler ist doch das Ding, das individuell je Anwendung erstellt werden soll, oder?
Dann musst du, damit die Klassen wie gewünscht funktionieren bei der ersten erwähnten Variante von dir jedesmal den Errorhandler prüfen, ob die entsprechenden Bedingungen richtig gesetzt sind. Damit wird definitiv die Funktionsfähigkeit der Klasse vom Errorhandler abhängig.

Bei Variante 2 und 3 ist das nicht mehr der Fall, wenn ich davon ausgehe, dass diese Standardstruktur des globalen Errorhandlers in jeder Anwendung enthalten ist.
Falls der globale Errorhandler fehlt, verändert sich das Verhalten der Klassen, bei denen damit programmiert wurde, ohne dass ich spezielle Eigenschaften der Klasse per Code veränderte. Das betrachte ich nicht als optimale Kapselung.

mfg
Josef

 

Ah oki ... Du verstehst mich falsch. *wink.gif*

Aus dieser Sicht hast Du natürlich völlig Recht und es wäre auch Bullshit, da die Klasse nicht mehr funktioniert wenn mal kein GEH im Projekt ist.

Deswegen war das auch nicht meine Intention.

Nimm das Klassendesign von ein paar Seiten zuvor, da wo wir darüber geredet haben ob nun die Klasse bei einem Fehler ein Error-Event und ein Err.Raise falls unbeantwortet beinhalten soll oder nicht. Die Klasse ist durch den von mir angedachten/überlegten API-Style völlig unabhängig von irgendeinem globalen Error-Handler und hat Ihre eigene Logik wie mit Fehlern innerhalb der Klasse zumzugehen ist ... und zwar völlig ohne Feedback vom Klassen-Nutzer.

Das muss natürlich so bleiben. Die Klasse muss sauber und ohne Fehlfunktionen auch ohne den GEH laufen.

Aber ... so ein Klassendesign hat in 2 Punkten auch einen groben Nachteil:

1. Fehlender Anschluß an den globalen Error-Handler für Fehlerprotokoll

Also, wie bekomme ich das jetzt an den globalen Error-Handler angeschlossen zur Protokollierung der Fehler ohne jedesmal in den klassennutzenden Prozeduren die Fehler in der Klasse an den globalen Error-Handler weiter zu reichen.

2. Projektspezifische Fehlerbehandlung

Fehler in der Klasse müssen in der aufrufenden Sub gehandelt werden und projektspezifische Fehlerbehandlungen aus der aufrufenden Sub angesprungen/aktiviert werden.

Genau diese beiden Problempunkte erledige ich mehr als elegant, sauber und übersichtlich mit dem GEH und ich kann projektspezifische Fehlerbehandlungen oder -aktionen völlig aus dem Klassendesign raushalten.

Gruß

Rainer