Office: (Office 2003) Error handling

\@ Sascha

Leider muss man wahrscheinlich doch zwingend prüfen.

Konnte zwar nicht den Inspector testen weil ich (noch) kein Geld ausgeben wollte aber die anderen Geschichten wie z.B. CallStack werden nur bei einem Fehler neu eingelesen.

Sprich hast Du in einer Sub einen Fehler und wertest 10 Sub später das CallStack-Object aus hast Du immer noch die Daten des Fehlers von vor 10 Subs drinnen.

Was dadurch das Heranziehen der Rückgabe des CallStack oder des ErrEx-Objectes zur Fallentscheidung ob ein Fehler in einer aufgerufenen Unter-Routine aufgetreten ist oder nicht unmöglich macht.

Leider gibt es auch nirgendwo eine Methode um den Fehlerspeicher/CallStack-Speicher des ErrEx-Objectes zu clearen. Oder hast Du eine gefunden?

Das ist irgendwie leicht ungeschickt gemacht. ^^

EDIT: Als Workaround könnte man sich vllt darüber behelfen das normale Err-Object auszuwerten und bei jedem Ansprung des globalen Error-Handlers das dann mit Err.Clear zu löschen. Bloss gefallen tut mir das nicht. *g*

Da sehe ich eine ganz große Stärke des Produktes. Man braucht keine einzige Zeile Fehlercode-Behandlung kann aber im globalen Error-Handler dezidierte Fallentscheidungen einbauen ... dadurch das der CallStack alle Prozeduren die beteiligt sind zurück gibt und auswertbar macht (inkl. aller Variablen-Inhalte), kann man tatsächlich pro Fehlernummer ein Select Case auf die Prozeduren einbauen, den Fehler damit global behandeln und je nach Ergebnis der Behandlung entscheiden wie nun weiter gemacht wird.

Gruß

Rainer

 

Wow! Das ist mal ne echte best-practice Diskussion geworden!

 

und nützlich vor allem...
hatte vorgesten einen Fall, der zwar nicht unbedingt was mit Fehlerbehandlung zu tun hat, für den ich aber aus dieser Diskussion hier die Lösung extrahiert habe.

Eine Funktion, die einen Double-Wert zurückliefert, liefert 0 auch wenn keine Zuweisung innerhalb der Funktion erfolgt ist. Nun kann 0 aber ein gültiger Rückgabewert sein. Wie also kennzeichnen, dass hier die 0 nicht weiter beachtet werden darf? Es war dann hier die Rede davon, eine Boolean-Variable zu führen, die den Erfolg der Funktion markiert. Ich hab dann in meinem Fall eine Variable global deklariert, deren Wert ich dann immer ändere.
Denkbar wäre auch die Rückgabe eines Strings gewesen, der dann aber erst wieder in Funktionswert und Boolean aufgeteilt werden müßte...

 

Das ist nicht empfehlenswert. Es wurde doch geschrieben, dass die Übergabe des (oder der) Parameter, dessen Wert geändert werden soll, per ByRef (statt ByVal) erfolgen sollte.

 

Wenn die Funktion keinen Wert zurückgeben kann, weil ein Ausnahmefehler aufgetreten ist, würde ich diesen an die aufrufende Prozedur weitergeben.
Ich breche lieber eine Stufe zu hoch ab, als eine versteckte Fehlerumgehung im Code zu haben. Denn irgendwann vergesse ich einmal den Rückgabewert zu überprüfen und schon habe ich mir falsche Werte eingefangen und weiß gar nicht, dass ich vielleicht sogar falsche Parameter übergebe, die den Fehler auslösen.
Wenn natürlich die API-Variante mit ByRef-Wertübergabe konsequent umgesetzt wird, ist das auch in Ordnung. Der dadurch entstehende Code wird aber etwas umständlicher zu schreiben sein.

Auch wenn es nicht besonders gut für VBA passt, empfehle ich trotzdem einmal die Entwurfsrichtlinien für Ausnahmen von Microsoft für MS.net zu lesen. Ein paar Anregungen kann man sich daraus auch für VBA holen.
Z. B.:

Eines muss man bei der Fehlerbehandlung aber unterscheiden: Erstelle ich eine Fehlerbehandlung in einem Code-Modul, dass ich möglicherweise auch in anderen Anwendungen wiederverwenden will oder erstelle ich eine Fehlerbehandlung in der Ereignisbehandlung eines Click-Ereignisses, das der User durch betätigen einer Befehlsschaltfläche auslöst und somit die oberste Aufrufhierarche darstellt.

mfg
Josef

 

Das wäre jetzt aus meiner Sicht nicht wirklich günstig ... genauso wenig optimal wie meine ursprüngliche Umsetzung in solchen Fällen wie Du beschreibst: Die Rückgabe über einen Variant-Typ zu lösen, der eben NULL oder EMPTY (je nach Geschmack) zurück gibt wenn ein Fehler statt fand.

Die Idee mit dem API-Style war ja - wie hcscherzer schon schrieb - , dass die Funktion an sich gar keinen "Arbeitswert" direkt zurück liefert sondern nur noch den Long Wert des Fehlers ... ist die Rückgabe 0 dann ist alles okay, ist die Rückgabe 0 dann ist was schief gelaufen.

Die Rückgabe des Arbeitswertes erfolgt dann über ByRef übergebene Parameter.

Also quasi anstatt so:

Code:

dann so:

Code:

@ Josef P.

Wenn man sich konsequent daran hält finde ich sogar das der Code einfacher zu schreiben wird ... und irgendwie auch sauberer (gefühlt).

Ich habe spaßeshalber mal mit dem Thema "Fehlerbehandlung Like API" in einer Klasse die eh eine eigene unabhängige Fehlerbehandlung bekommen sollte angefangen.

Wenn man eine Routine (oberste Aufrufebene) baut die nur und ausschließlich die Ablauflogik/-verzweigung und Fehlerbehandlung handelt und alle anderen Aufgaben in Hilfsfunktionen/-routinen (untere Aufrufebenen) auslagert die nach dem API-Style als Rückgabe prinzipiell einen Long-Fehlerwert liefern wird das eine richtig übersichtlicher, sehr gut zu wartender und zu lesender Aufbau.

Richtig perfekt würde das Ganze wohl dann wirklich mit dem SimplyVBAErrorHandler ... der regelt dann die Ausgabe und Ausnahmebehandlungen wenn ein Fehler auftritt.

So gut wie keinen Anschluß an irgendeine Fehlerbehandlungsroutine im produktiven Code ... ausser man will Variablen-Inhalte verändern, dass muss man wohl immer noch im produktiven Code direkt regeln ... ABER ohne Anschluß an die globale Fehlerbehandlung. Habe mir gestern nochmal das Bookmark-Object angesehen und war schlicht begeistert ... man kann nach einem Ansprung des globalen Error-Handlers auswerten ob im Prozedur-Code eine Bookmark für den fehler gesetzt ist und dann springt wird aus dem globalen Error-Handler direkt auf die Bookmark im Code zurück gesprungen nachdem (oder vor dem ... je wie man es programmiert) die normale Fehlerbehandlungsroutine abgelaufen ist.

D.h. man kann wirklich die komplette Ausnahmebehandlung von Fehlern aus dem produktiven Code in den globalen Error-Handler auslagern ohne das man in irgendeiner Prozedur einen Anschluß an den Error-Handler programmiert hat ... nur eine Zeile mit einem Bookmarks für bestimmte Fehler muss man noch im produktiven Code setzen, damit der globale Error-Handler weiss ob er zurück in die Prozedur und wenn ja an welche Stelle springen soll.

Gut, der eine mag es unübersichtlich finden wenn Aktionen die auf einen bestimmten Fehler erfolgen sollen nicht direkt im Code sind, sondern in einem ganz anderen Modul stecken und er im normalen Code noch nichtmal eine Ansprung-Anweisung vorfindet ... aber das könnte man ja mit Kommentaren ausgleichen wenn man will.

Damit sind wir genau beim Thema, mit dem SimplyVBAErrorHandler kannst Du nix mehr vergessen und musst nicht aus Sicherheitsgründen gleich mal vorsichtshalber bis direkt in die obere Ebene abbrechen.

Gerade das Thema falsche Parameter oder gleich Parameter-Prüfung könnte man auch direkt in die globale Fehlerbehandlung auslagern ... Fehlerbehandlung wird angesprungen, verzweigt dann durch die Auswertung des CallStack-Objectes per Select Case in die gesonderte Fehlerbehandlungsroutine für die Prozedur nach Abarbeitung der Prozedur und der fehlerprotokollierung wird dann zurück an die im produktiven Code gesetzt Bookmark gesprungen aus der Fehlerbehandlung ... ist keine gesetzt dann wird eben nicht zurück gesprungen und die Prozedur abgebrochen ... die weiss dann auf Grund der Long-Rückgabe das ein fehler erfolgt ist und handelt dann im Sinne der Ablauflogik weiter.

Gruß

Rainer

 

Mit ein bißchen Nachdenken hab ich Rainer´s Beispiel jetzt auch verstanden bzw. kann mir erklären, was eigentlich gemeint ist... wenn es denn um eine Fehlerbehandlung in der Funktion geht.

Code:

führt bei mir zu der Message-Box "kein Fehler", strVariable ist aber nicht zugewiesen worden weil beispielsweise Bedingungen in der Funktion das nicht zugelassen haben. Wenn ich lngRet überprüfe, ist kein Fehler aufgetreten... und ich arbeite mit einem falschen Wert weiter. Oder bin ich jetzt völlig blind?

Im Rahmen einer Fehlerbehandlung ist die Vorgehensweise in meinen Augen sehr sinnvoll, aber auf meinen Fall nicht anwendbar

Code:

liefert in der Variante die MsgBox "Fehler aufgetreten" und ich weiß, dass der Rückgabewert der Funktion nicht verarbeitet werden soll. Wenn man das besser machen kann, so zeige ich mich gerne lernbereit *wink.gif*

 

Bei Klassenmembern willst du das auch einbauen?
Ich kann mir das ja noch für Funktionen in Standardmodulen vorstellen, aber bei Klassen halte ich das für kontraproduktiv, weil du nur noch Methoden und keine Eigenschaften mehr nutzen kannst.
Das wird dann meiner Ansicht nach ein Konstrukt, bei dem die Fehlerbehandlung die Schnittstelle der Klasse bestimmt. So etwas kommt mir etwas eigenartig vor. *wink.gif*

mfg
Josef

 

Nein, Du bist jetzt nicht völlig blind.

Okay, in Deinem Beispiel hast Du die Zuweisung der Err.Number als Funktionsrückgbe auskommentiert ... damit ist die Rückgabe natürlich immer 0 (ist ja ein Long Wert).

Aber auch wenn Sie nicht auskommentiert wäre, würde immer noch eine 0 zurück gegeben werden weil ja kein Laufzeit-Fehler in der Sub aufgetreten ist ... einen Wert nicht zuweisen löst ja keinen Fehler aus.

Das Prinzip/die Systematik bei der Vorgehensweise ist nur dafür gedacht Fehler die in der Sub aufgetreten sind zu melden und nicht in der Sub zu prüfen ob der Rückgabewert im Sinne der Programmlogik gültig ist.

Die Entscheidung was bei einem Fehler zu tun ist und die Prüfung ob der Rückgabewert aus Sicht der Programmlogik einer gültiger Wert ist, verlagert sich dabei in die aufrufende Sub.

Und in Deinem Beispiel versagt schlicht die Ablauflogik der aufgerufenen Sub (Wert wird nicht gesetzt ist ja ein Fehler in der Ablauflogik ^^) und da gibt es einfach keinen Laufzeitfehler zurück.

Die Problematik ist doch schlicht das Du nun die Gültigkeitsprüfung ob der Wert aus Sicht des Programmablaufes gültig ist in die aufgerufene Routine verlegst: Eine leere Rückgabe muss ja nicht immer zwangsläufig ein ungültiger Wert sein. kann ja durchaus auch eine gültige Rückgabe sein.

Stell Dir die Rückgabe der Variable als Ergebnis einer Suchfunktion vor, z.B. mal ganz einfach so:

Code:

Dann wäre eine leere Rückgabe oder auch Null als Rückgabe durchaus ein gültiger und möglicher Wert.

Aber wenn der User das Kriterium dynamisch zusammen stellt, kann durchaus auch mal die Abfrage auf etwas passieren was nicht existiert und dann gibt es einen Laufzeitfehler.

Die Rückgabe der Variable ist in beiden Fällen Null ... bei nicht gefunden oder Laufzeitfehler. Aber diese Prüfung kommt nun in die aufrufende Sub rein:

Code:

Die aufgerufene Sub für die Rückgabe des Suchergebnisses kann ja nicht entscheiden was nun aus Sicht der Programmlogik ein gültiger Wert ist und was nicht.

Das tut Sie aber in Deinem Falle wo sie selbst die globale Variable lngRet an Hand der Feldlänge auf True oder False setzt.

Für die nächste Routine die Du schreibst kann eine leere Rückgabe oder Null-Rückgabe der Hilfsfunktion durchaus ein gültiger Wert sein wenn er nicht auf Grund eines Fehlers passierte.

Jetzt müsstest Du nun in der Hilfsprozedur die Gültigkeitslogik umschreiben oder eine neue Hilfsprozedur erstellen da Du die Alte - die lngRet an Hand der Feldlänge setzt h- ier nicht mehr passt weil lngRet dann False wäre obwohl das in dem Falle aus Programmlogik-Sicht nicht mehr stimmt.

Die Logik ob richtig oder falscher Rückgabewert aus der Hilfsprozedur raus zu nehmen, sorgt dafür das die Hilfsprozeduren flexibler werden und mehrfach ansprechbar sind ... egal aus welchem Programmablauf heraus.

Ich hoffe ich konnte es irgendwie verständlich rüber bringen was ich meine? *wink.gif*

Gruß

Rainer

 

Beim ersten Lesen... nein *upps
Hab hier im Büro jetzt aber auch nicht den Kopp frei, werde mir das heut Abend nochmal einverleiben. Dann klickerts bestimmt und ich hab wieder was gelernt *wink.gif*

 

\@ Josef

Natürlich nicht für Propertys ... das wäre ja Bullshit. *wink.gif*

Aber die ganzen internen Funktionen und aber auch öffentlich zugängliche Funktionen könnten so gestaltet werden.

Das sehe ich komplett anders ... nämlich das völlige Gegenteil ist der Fall.

Ich denke gerade mit der Vorgehensweise werden Klassen freier und nicht mehr durch die Fehlerbehandlung des Projektes bestimmt.

Mach ich heute eine Klasse für mein Projekt und will diese Klasse ohne Nachdenken auch in anderen DB's nutzen können oder gar zur Weitergabe an Dritte zur Verfügung stellen, dann darf/sollte ich sie nicht an meine globale Fehlerbehandlung anchliessen sondern muss ihr eine eigene Fehlerbehandlung spendieren.

Durch die Vorgehensweise im API-Style habe ich die Fehlerbehandlung schon von Haus auf drinnen und brauche mich nicht mehr drum zu kümmern. Nur intelligenterweise ein Error-Ereignis rein programmieren damit mögliche Horcher reagieren können und das ist dann pro Prozedur eine Zeile die bei Error-Number 0 das Error-Ereignis auslöst und fertisch.

Vor allem entsteht keine Gefahr durch den Anschluß der Klasse an die Fehlerbehandlung der Klassen-Nutzer. Die hier möglicherweise nicht einen Code-Abbruch vorsehen wenn an Stelle X ein Fehler auftritt sondern durchlaufen lassen oder wenn Klassennutzer Sachen die ich als Private programmiert habe sich durch eine Wandlung in Public anderweitig nutzen und auf einmal einen Fehler zurück geworfen bekommen an einer Stelle wo sie keine Fehlerbehandlung drinnen haben.

Der Nutzer muss nur noch das Error-Ereignis abhorchen oder auf die Fehler-Rückgabe reagieren wenn er eine Public Function der Klasse abgerufen hat.

Für Property stellt man noch ein Error-Property zur Verfügung das er dann wenn es wichtig wird auf einen aufgetretenen Fehlerwert prüfen kann.

Damit ist die Klasse völlig unabhängig von der Fehlerbehandlung des Projektes und ist auch abgesichert dagegen das Sie in fremden Projekten nicht zwangsläufig Abstürze verursacht weil sie z.B. einen Fehler an eine aufrufende Sub zurück wirft die z.B. gar keine Fehlerbehandlung hat.

Ich denke das gerade für Klassendesign die Trennung von Fehlerbehandlung und Ablauflogik ein enormer Vorteil für die Einsatzflexibilität wäre.

Gruß

Rainer

 

Natürlich nicht für Propertys ... das wäre ja Bullshit.

Und was machst du dann bei Property-Prozeduren? Gibst du dann den Fehler doch nach oben weiter (z. B. indem du z. B. gar keine Fehlerbehandlung einbaust)?

Diese Fehlerbehandlung muss aber nicht zwangsweise in der Klasse untergebracht sein. Da du vermutlich nicht nur eine Klasse sondern mehrere Klassen gleichzeitig wiederverwenden wirst, könnte man das als eine Art Framework bzw. Bibliothek sehen. Oder anders ausgedrückt: stelle dir vor, du würdest die wiederverwendbaren Klassen in einer extra mde/accde bzw. in einer dll sammeln. Warum sollte dort jede Klasse unbedingt ganz alleine funktionieren und keine weiteren Hilfsklassen bzw. Hilfsmodule verwenden?

Aber genau da machst du ja nicht, wenn du bei jeder Prozedur auswertest, ob die Rückgabe ohne Fehler war.

Falls du den SimplyVBA Global Error Handler einsetzt, brauchst du auch keine Rückgabe eines Fehlercodes einbauen, da der sowieso bis nach außen (bzw. an die Stelle mit der ersten Fehlerbehandlung) abbricht, wenn der Fehler nicht an anderer Stelle durch eine allgemeine Fehlerbehandlung aufgehoben wird.

Aus diesem Gesichtspunkt verstehe ich nicht, was an der Kombination SimplyVBA Global Error Handler mit eine Fehlercode-Rückgabe nach API-Stil bringt.
Bei Verwendung des SimplyVBA Global Error Handler ist es doch ganz einfach: Keine allgemeine Fehlerbehandlung in Klassen - sondern nur für jene Fehler, die im Klassencode beseitigt werden können.
Und die Funktionsweise der allgemeinen Fehlerbehandlung regelt man nur in der jeweiligen Access-Anwendung ... also genauso wie man es auch mit VB.net oder C# & Co. machen würde.

Bei Klassen ist es meiner Ansicht nach ein falsches Design, wenn die Klasse die Fehler nicht nach außen weiterreicht sondern alles ignoriert und nur noch die Erfolgsmeldung über die Funktionsrückgabe durchführt.
Dass es natürlich Methoden geben kann, bei denen es sinnvoll ist, bestimmte Fehler zu ignorieren, ist klar, das hat aber nichts mit einer allgemeinen Behandlung von Ausnahmen zu tun.

Das ganze Gemurkse mit der allgemeinen Fehlerbehandlung ist eigentlich nur notwendig, weil VBA die Entstehungsgeschichte nicht ausgeben kann. Wenn man dafür aber den SimplyVBA Global Error Handler verwendet, tritt diese Problem gar nicht auf.

mfg
Josef

 

Das verstehst Du falsch ... ich stelle mir das so vom Grundprinzip her vor:

Code:

Und in der aufrufenden Sub ohne Eventhandling weil z.B. in allgemeinem Modul steht so:

Code:

So in etwa vom Grobprinzip her.

Genau die Sicht den Fehler nach aussen zurück werfen finde ich aus meiner rein persönlichen Sicht der Dinge das falsche Design für eine Klasse.

Ich muss doch den Klassen-Nutzer dagegen absichern das seine Anwendung möglicherweise abschmierrt wenn in meiner Klasse ein Fehler aufgetreten ist und er die Fehlerbehandlung versäumt hat. Z.B. wenn er aus einem reinen 2- oder 3-Zeiler-Code zugreift und sich denkt : Beim einfachen Auslesen einer String-Property brauche ich ja keine großartige Fehlerbehandlung.

Ganz einfach weil das Fehlermeldungs-Handling an sich und auch mögliche Fehlerbehebungsversuche (wie z.B. Neuaufbau der Verbindung zum BE oder ähnliches) durch den SimplyVBA Global Error Handler völlig losgelöst von der Programmlogik abläuft.

Die Programmlogik selber braucht aber auch eine Fehlerauswertung um zu entscheiden wie nun weiter zu verfahren ist.

Im obigen Klassendesign würde ja im Normalfall die Problematik entstehen das zwar die Programmlogik jetzt weiss das ein Fehler aufgetreten ist und nun selber entscheidet wie damit zu verfahren ist ... Programmabbruch bis in die oberste Aufrufeben, Anspringen von anderen Zweigen der Programmlogik oder eigene Fehlerbehebungsversuche (z.B. Ersatzwert in Variablen einlesen) ... ABER es gibt keine Meldung an den User, es gibt keinen Logeintrag für den Programmierer und mehrfach verwendbare Fehlerbehebungsroutinen müssten direkt aus der Programmlogik angesprungen werden ... und ein Projekt so zu programmieren ist ja auch nicht sinnvoll weil man so während der Entwicklung i.d.R. kaum bis gar keine Compiler-Meldungen über Fehler bekommt.

Aber genau diese Problempunkte umgehe ich perfekt und kann die ganze Abhandlung - ohne eine einzige Zeile Code einzubauen - mit dem SimplyVBA GEH sauber gekapselt durchführen.

Mir geht es persönlich rein um die Trennung von Ausnahmebehandlung an sich und Bestimmung des weiteren Ablaufs in der Programmlogik.

Die Programmlogik wird halt ausser Kraft gesetzt und durch absolutistische Anweisungen der Fehlerbehandlung ersetzt: Brich komplett ab oder mach weiter ... mehr Anweisungen jibbet nicht und das ist mir für einen intelligenten Programmablauf eindeutig zu wenig. *wink.gif*

Und die Möglichkeiten Fallentscheidungen in den Error-Handler der Prozedur einzubauen sind mir zu aufwändig, erhöht die Anzahl der Code-Zeilen enorm, macht den Code unübersichtlich/schwerer nachzuvollziehen und macht ja auch keinen Sinn aus der Sicht das wir alle übereinstimmen das erwartete/bekannte Fehler nicht im Err-Handler abzuhandeln sind sondern eine Sache der Programmlogik sind.

Gruß

Rainer

 

Und wenn niemand auf den Fehler reagiert, weil die Klasse ohne Withevents verwenden wird, wird er Fehler einfach ignoriert und vbNullstring zurückgegeben?
Oder würdest du überall folgendes reinschreiben:
Code:

Wo ist dann aber die Trennung zw. der Ausnahmenbehandlung und dem eigentlichen Ablaufcode?
Vor allem: Was macht dieses Konzept übersichtlicher im Vergleich zu weitergereichten Fehlermeldungen?

Ein Error-Ereignis in einer Klasse kann durchaus nett sein, man muss aber meiner Ansicht nach unbedingt prüfen, ob darauf reagiert wurde und den Fehler nur dann nicht auslösen, wenn über das Ereignis mitgeteilt wurde, dass das nicht passieren soll. Wird nichts mitgeteilt, weil z. B. niemand auf das Ereignis reagiert hat, wird der Fehler ausgelöst, da das sonst zu einem On Error resume next wird.

Nimm dir als Beispiel Form.Error. Wenn du auf das Ereignis reagierst und über Response nicht antwortest, kommt es zur Fehlermeldung.

Ganz einfach weil das Fehlermeldungs-Handling an sich und auch mögliche Fehlerbehebungsversuche (wie z.B. Neuaufbau der Verbindung zum BE oder ähnliches) durch den SimplyVBA Global Error Handler völlig losgelöst von der Programmlogik abläuft.

Wo die Fehlerbehandlung läuft ist nebensächlich. Ausschlaggebend ist, dass es eine gibt. Und wenn die den Fehler nicht aufhebt, dann kommt es bei deinen Funktionen nicht zur Übergabe des Fehlercodes - außer du baust so etwas wie On Error resume next ein.

Das wäre nach meiner Ansicht nach auch richtig, nur erkenne ich das in deinen Vorschlägen nicht. *wink.gif*

mfg
Josef

 

Wer will kann das mit einbauen ... wo ist das Problem?

Wobei aber ... ist es wirklich notwendig und sinnvoll? Ich glaube an sich nicht.

Wieso soll ich den Nutzer einer Klasse zwingen auf ein Error-Ereignis zu reagieren? Mir persönlich wäre das zuviel Gängelei. Wer nicht reagieren will soll es bleiben lassen ... möglich das jemanden auch nur ausreicht Null/Leer zurück zu bekommen und seine Programmlogik entscheiden zu lassen was mit der Rückgabe kein Inhalt zu tun ist.

Das ist nicht Sache der Klasse und vor allem würde ich das Handling einschränken auf Aufrufe aus anderen Klassen und das Handling bei Aufrufen aus allgemeinen Modulen erschweren/abändern müssen.

Der Fehlercode wird auf Anfrage an den Anfrager übergeben, kommt keine Anfrage nachdem Fehlercode läuft die Klasse per On Error Resume Next durch, bzw. entscheidet in Ihren Funktionen ja selber durch die Rückgabe der Fehlerwerte was Sie tut bei einem Fehler ... unabhängig davon was der Klassen-Nutzer nun in der Ablauflogik seiner Prozedur festgelegt hat.

Gerade wenn man konsequent vom Black-Box-Prinzip beim Klassendesign ausgeht ist das die perfekte Lösung. Die Klasse löst niemals einen Laufzeitfehler aus, aber meldet jeden Fehler über das eigene "Error-Object" (also die Error-Propertys) auf Anfrage zurück und intern reagiert sie in ihrer Ablauflogik selber auf Fehler ... der Klassen-Nutzer muss sich nicht drum kümmern wie das geschieht.

Hhhmmm ... ich glaube ich muss mal dringend an meiner Rhetorik arbeiten. ^^

Ich denke Deine Überlegung ist schlicht das jede Prozedur eine eigene Ausnahmebehandlung benötigt und wenn es nur ist einen aufgetretenen Fehler nach oben zurück zu werfen.

Und genau da bin ich der Ansicht das eben nicht jede Prozedur eine Ausnahmebehandlung benötigt, sondern nur die Prozeduren die die Ablauflogik beinhalten. Ob in einer unteren Aufrufebene ein Fehler aufgetreten ist, bekommt die obere Aufrufebene dann über den Long-Wert mitgeteilt und entscheidet nun ob Sie in einen Zweig zur Behandlung der Ausnahme an dieser Stelle abzweigt oder abbricht.

Das ist in meinen Augen reine Programmablauf-Logik und da hier keinerlei Fehlerbehandlungen definiert sind ist damit die Programmablauf-Logik von der Ausnahme-/Fehlerbehandlung sauber getrennt.

Wenn dann ein Laufzeit-Fehler auftritt legt man den Umgang damit im SimplyVBA GEH fest, inklusive Versuche bestimmte Fehler selbst zu korrigieren.

Konnte der Fehler korrigiert werden entscheidet der GEH auf weitermachen im Resume-Mode, konnte der Fehler nicht behoben werden entscheidet der GEH auf Prozedur-Abbruch-Mode und wurde eine Prozedur von einer bestimmten anderen Prozedur aufgerufen entscheidet der GEH in diesem Falle auf Goto-Next-Error-Label-Mode und bei einem ganz speziellen Fehler entscheidet der GEH zum gesetzten Bookmark in der fehlerhaften Prozedur zu gehen und in einem ganz anderen Falle entscheidet der GEH auf Abbruch der kompletten Prozedur-Aufruf-Kette.

Diese ganz Logik was zu tun ist wenn ein Ausnahmefehler auftritt in einer Prozedur-Aufruf-Reihe steht nun nicht mehr in der Porzedur die die Programmlogik steuert sondern im GEH.

Damit ist eine perfekt sauberer Trennung vorhanden zwischen Programmablauflogik und Fehlerbehandlungslogik.

War es jetzt verständlicher worauf ich hinaus will? Ich vermute wahrscheinlich nicht ... womit wir wieder beim Thema wären, dass ich dringend an meiner Rhetorik/Ausdrucksweise arbeiten muss. *wink.gif*

Gruß

Rainer