Office: (Office 2003) Error handling

Sorry, meine Fehler ... sollte natürlich heissen Klassen-Instanz.

Ich hatte zumindest Deine Aussage bisher so verstanden und auch die Beschreibung Deiner Überlegungen zum Thema Fehlerbehandlung das Du auch den Hilfsfunktionen eine eigene Behandlungslogik für Fehler mit gibst.

Also anstatt eines Ergebnisses aus dem man eine Fehlfunktion ableiten kann, einen Fehler an die aufrufende Sub zurück wirft. Damit entscheidet in meinen Augen die Hilfsprozedur über die weitere Ablauflogik des projektbezogenen Codes. Deren Ablauflogik verschiebt sich ja jetzt von dem normalen Programm-Code auf den Fehlerbehandlungs-Code.

Aber vermutlich reden wir mal wieder nur aneinander vorbei und meinen im Prinzip das Gleiche. *wink.gif*

Okay ... was habe ich dann falsch verstanden an Deiner Aussage das Du auch bei einer Hilfsfunktion ala FLookUp wissen/zurück haben willst wenn ein Fehler wegen nicht vorhandener Tabelle auftritt und Du darauf im weiteren Ablaufcode reagieren willst? Ist das nicht ein Abfangen des Fehlers nicht vorhandene Tabelle im FE?

Gruß

Rainer

 

Das wäre nicht das erste Mal. *biggrin.gif*

Und ich behaupt, dass dein Vorschlag viel mehr die Logik der Fehlerbehandlung in die Hilfsprozeudr verlagert, weil du dort den unerwartetn Fehler aufhebst und einen Dummy-Rückgabewert erzeugst.
Wenn ein Fehler auftritt gibt es bei mir ganz einfach keine Rückgabe nicht einmal eine falsche, weil ich einen Laufzeitfehler auslöse.
Bitte beachten: ich schreibe hier immer noch von nicht erwarteten Fehlern. Bei Fehlern die die Hilfsprozedur aufheben kann, weil der Programmierer eine Sonderbehandlung für die Fehlerbeseitigung einfügte, gilt das natürlich nicht. (Beispiel für Sonderbehandlung: Fehler = DB-Verbindung nicht vorhanden => In der Fehlerbehandlung wird versucht die Verbindung erneut herzustellen. Wenn das klappt, kann ganz normal weitergemacht werden.)

Als Beispiel für eine Fehlerauslösung: Zweierlogarithmus berechnen:
Code:

Bei so einer Funktion würde ich vermutlich gar keine Fehlerbehandlung einbauen, weil nur die gleichen Fehler wie bei Log(..) auftreten können.

Falls ich doch eine Fehlerbehandlung einbauen würde, würde ich bei 0-Übergabe auf jeden Fall einen Fehler auslösen, weil der Nutzer dieser Funktion es verabsäumt hat, auf 0 zu prüfen. Weiters würde ich alle Fehler die die Log-Funktion bzw. die Division auslöst weitergeben. Ich würde also das Gleiche wie die Log-Funktion machen und nicht irgendeinen Sonderweg einschlagen, damit bei 0-Übergabe kein Fehler erzeugt wird. Wer 0 als Parameter an diese Funktion übergibt ist selbst schuld, da er wissen müsste, dass Logn(0) nicht berechnet werden kann.

Bei anderen Funktionen, denen ein nicht zulässiger Parameterwert übergeben wird (typischer Fall: bei Parameter mit Enum-Werten bei denen man unter VBA jederzeit eine beliebige Zahl eintragen könnte), löse ich ebenfalls einen Fehler aus und setze keinen Ersatzwert ein, weil die Hilfsfunktion nicht wissen kann, ob der Ersatzwert von der aufrufenden Prozedur gewünscht ist. Wer Mist übergibt muss damit rechnen, dass gemeckert wird. Somit ist die aufrufende Prozedur selbst schuld, wenn die nicht zulässige Parameterwerte an eine Prozedur übergibt und die Prozedur einen Fehler auslöst.

mfg
Josef

 

Ohja ... ^^

Genau darum geht es. Den kannst Du in der aufrufenden Sub dann aber auch nur in der Fehlerbehandlung weiter verarbeiten/reagieren.

Klar, wenn es eh Ziel ist bei einem Fehler in einer Unteroutine den kompletten Ablauf der darüber liegenden Aufruf-Ebenen sofort und ohne Diskussion abzubrechen ist es ja okay.

Aber zumindest bei mir kommt es öfters Mal vor, dass ich dann nicht den kompletten Ablauf abbrechen lassen will sondern vllt bei einem Fehler nur in einen anderen Zweig aus der Programmlogik zu wechseln.

Um es vielleicht besser zu verdeutlichen ein Beispiel was ich meine:

Ich programmiere gerade ein Formular für ein sehr aufwändiges DataGrid (inkl. Report-Ausdruck, Export, Suchfunktionen etc.). Dieses soll einmalig erstellt werden und dann mehrfach wieder verwendbar sein ... z.B. als UFO und aber auch als mehrfache instanzierbares eigenständiges HF.

Daher habe ich die Befüllung des Grids mit Daten und die verschiedenen Einstellungsblöcke ausgegliedert in eigene Prozeduren die eigene Ereignisse auslösen auf die dann ein steuerndes Formular oder der Aufruf selber reagieren kann und selber noch individuelle Einstellung im Grid vornehmen könnte eingebaut.

Tritt ein Fehler in der Befüllung mit dem Recordset auf, ist klar das ich alles weitere abbrechen lasse.

Tritt aber nur ein Fehler z.B. bei den Einstellung für die Spaltenbreite auf oder beim Einlesen der Icons (z.B. weil User aus welchen Gründen auch immer ein Icon aus dem Image-Ordner rausgelöscht hat), will ich es zwar wissen aber hier wäre es völlig unnötig und auch nicht sinnig dann die Anzeige des Grids komplett abzubrechen.

Würde ich nun die Routinen für die Befüllung und die Einstellungen des Grids aber jeden Fehler zurück werfen lassen muss ich die Prüfung ob ich bei einem Fehler abbrechen lassen will oder weiter fortfahren lasse oder was auch immer in die Fehlerbehandlung verlagern oder diese Logik den ganzen Unterroutinen selbst mit geben.

So habe ich eine aufrufende oberste Ebene die nix anderes macht als die Routinen in der Reihenfolge abzuarbeiten, deren Rückgabewerte auf Korrektheit zu prüfen und entsprechend auf die Rückgabewerte zu reagieren und dann je Fall zu entscheiden was weiter zu tun ist ... und auch nur hier erfolgt der Anschluß an den globalen Error-Handler.

Ich finde das wesentlich übersichtlicher als wenn ich diese Logik in der Fehlerbehandlung einbauen müsste (wo ich dann natürlich erstmal noch eine Fall-Prüfung einbauen müsste nämlich aus welcher Prozedur der fehler kommt) oder gar die ganzen einzelnen Routinen mit einer eigenen Logik bestücken müsste.

Erstens schreibe ich mir bei Letzterem dann mit mehrfach doppelten Code die Finger wund und zweitens fände ich es für die Wartung des Codes absolut negativ wenn ich nun in jeder einzelnen Routine die Ablauflogik prüfen müsste ... ich weiss doch schon nach einer Woche nicht mehr was ich wo wieso gemacht habe. ^^

Natürlich gibt es auch genug Hilfsroutinen wo man gleich komplett abbrechen kann wenn dort was schief läuft, wie z.B. Hilfsprozeduren für die Erstellung von Recordsets oder Connections, aber es gibt auch genug Sachen wo man nicht unbedingt zwingend abbrechen muss wenn es einen Fehler gibt.

Klar könnte man jetzt für die Fälle wo man eh komplett abbrechen muss eine anderen Fehlerbehandlung einbauen als für die Fälle wo man nicht zwingend abbrechen muss bei Fehler, aber im Sinne einer einheitlichen Vorgehensweise wäre das nicht wirklich hilfreich. *wink.gif*

Gruß

Rainer

 

Ich verstehe irgendwie das Problem nicht. Wenn der Fehler nur nebensächlich ist und für das Ergebnis der Prozedur keine Rolle spielt, dann muss man den ja nicht nach oben weiterreichen. Problem dabei: wie bestimmt man die "Auswirkung" eines unerwarteten Fehlers?

Das gilt auch für unwichtige Prozeduren, die z. B. nur irgendeine Anzeige einschaltet, bei der es egal ist, ob man sie sieht oder nicht.
Bei solchen Prozeduren kann man als Programmierer durchaus den Fehler direkt in der jeweiligen Prozedur behandeln und nicht nach oben weiterreichen.
Bei deinem Beispiel mit dem fehlenden Icon würde ich z. B. das Icon entweder aus der DB bzw. Anwendung nachladen, ein Ersatzicon verwenden oder einfach das Icon weg lassen und ein einziges Mal dem user die Meldung bringen, dass mit der Installation der Anwendung etwas nicht passt. Diese Meldung könnte man dann eventuell auch noch gleich mit einem Auswahldialog verbinden, damit der User das fehlende Icon ersetzen kann.

Das könntest du in der Fehlerbehandlung auch machen, wenn du eindeutige Fehlercodes verwendest.
Und wie schon üblich der Sicherheitshinweis: ich gehe immer noch von Ausnahmefällen aus und nicht von so etwas wie: lese die Datei und falls sie nicht vorhanden ist, erzeuge sie mit den Standardvorgaben.

Falls ich dich richtig verstehe, willst du in deiner Klasse bei Bedarf einen Fehler ignorieren. Diese Entscheidung willst du aber den Nutzer der Klasse überlassen.
Für solche Szenarien verwende ich ganz gerne Ereignisse, die dem Nutzer der Klasse mitteilt, dass gerade Fehler XYZ aufgetreten ist.
Im Prinzip so etwas die das Error-Ereignisse der Form-Klasse.
Über diese Variante habe ich dann sogar die Möglichkeit in der jeweiligen Methode in der der Fehler auftrat fortzusetzen.
Wenn man dann die Ereignisse genau genug kennzeichnet, weiß der Nutzer der Klasse auch, wo der Fehler auftrat.
Wird auf das Fehler-Ereignis nicht reagiert, löse ich den Fehler aus und teile so dem Aufrufer mit, dass etwas nicht passt.
Positiver Nebeneffekt: der Code der Fehlerbehandlung stört nicht den eigentlichen Code, weil er in einer ganz anderen Prozedur ist und man kann ähnliche Fehler an einer einzigen Stelle behandeln.
Nachteil: man kann in der Ereignisbehandlung natürlich nicht mehr mit den Prozedurvariablen der aufrufenden Prozedur vom Klassennutzer arbeiten.
Aber für die Entscheidung ob bei Fehler XY abgebrochen werden soll, ist das durchaus brauchbar, wenn man das nicht innerhalb der Klasse entscheiden kann.

mfg
Josef

 

Ich denke der Unterschied zwischen meiner Sichtweise zu dem Thema und Deiner Sichtweise wird durch unsere letzten beiden Posts schön sichtbar. *wink.gif*

Du reichst entweder den Fehler nach oben weiter damit er von der aufrufenden Sub in der Fehlerbehandlung abgearbeitet wird oder Du reichst ihn nicht weiter und setzte eine Programmlogik was bei Fehler zu tun ist in die aufgerufene Routine ein.

Genau das meinte ich ... die aufgerufene Sub kann nicht wissen ob es für die aufrufende Sub ein unerwarteter Fehler oder ein durchaus erwarteter Fehler ist.

Klar, aber janz ehrlich ... ist mir schlicht zu unübersichtlich und wieso sollte ich mit eigenen Fehlercodes rum hantieren wenn ich mir über einen Long-Wert als Rückgabe (um mal in der Richtung API zu bleiben) den direkten Fehlercode hole.

Und jetzt sind wir genau bei dem Chaos das ich mal ein paar Seiten zuvor angesprochen habe ... die eine Sub wirft den Fehler zurück, die andere Sub hat eine eigene Fehlerbehandlung und die nächste hat schlicht On Error Resume next weil sie völlig unwichtig ist.

Wie behält man da noch den Überblick wohin wiederverwendbarer Code verzweigt und ob ja auch keine Prozedur mit eigener Fehlerbehandlung angesprungen wird, was dann ja den Rückwurf eines unerwarteten Fehlers bis zur obersten Aufruf-Ebene verhindern würde.

Größere Funktionen können ja durchaus mal 10 oder weit mehr Unterroutinen inkl. Hilfsprozeduren anspringen bis sie durchgelaufen sind.

Also ich würde da ziemlich schnell den Überblick verlieren, ob da nun eine Routine dabei ist die mir den Rückwurf eines Fehlers an die oberste Aufruf-Ebene zu nichte macht oder nicht.

Sind wir wieder beim Thema ... was ist ein Ausnahmefehler? Meine Definition von Ausnahmefehler wäre: Alles womit ich an der Stelle nicht rechne.

Nimm direkt Dein Beispiel: Lies die Datei von der Festplatte

Rufe ich diese Funktion aus einer Sub auf die fest damit rechnet das die Datei da ist (vllt weil ich sie per Installation dahin geschaufelt habe) ist es ein Ausnahmefehler wenn die Datei nicht da ist. Für eine andere aufrufende Sub ist es kein Ausnahmefehler, weil ich an der Stelle damit rechne das die Datei möglicherweise nicht da ist.

Ist doch viel einfacher und imho sauberer mir die Meldung das die Datei nicht da ist über einen Rückgabewert der Funktion an die aufrufende Sub melden zu lassen um dann in der Routine die die Ablauflogik beinhaltet zu entscheiden ob ich nun in diesem Fall eine gespeicherte Vorlage auf die Festplatte knalle oder hier völlig überrascht bin und einen Ausnahmefehler auslöse oder einen Dateiauswahldialog anbiete um eine andere Datei auszuwählen, bzw. einen anderen Ordner anzugeben wo die Datei zu finden ist.

Du würdest nach Deiner Beschreibung den "Fehler" Datei nicht vorhanden in die Fehlerbehandlung der aufrufenden Sub reinrasseln lassen und dort wird dann entschieden was zu tun ist.

Aber das funktioniert auch nur wenn Du absolut 100% sicher bist das nicht zuvor eine andere unwichtige Routine angesprungen wurde die eine eigene Fehlerbehandlung oder gar ein On Error Resume Next beinhaltet.

Nö ... in keinster Weise. Ich will im Gegenteil jeden Fehler wissen, aber dann in der Ablauflogik entscheiden was zu tun ist und nicht in der Fehlerbehandlung.

Da sehe ich eben den Vorteil der Fehlerverarbeitung über Rückgabe-Werte ... der Einstieg in die Klasse wäre eine einzige Prozedur die ruft von sich aus nach der Klassen-Logik die benötigten Unterroutinen auf und prüft nach jeder Ausführung den Rückgabewert.

Tritt ein Fehler auf stehe ich an exakt der Stelle der Programmlogik wo der Fehler aufgetreten ist und kann nun über ein Ereignis dem Nutzer der Klasse mitteilen an welcher Stelle exakt welcher Fehler aufgetreten ist und kann dann auch noch die aktuell gültigen Übergabe-Parameter anzeigen lassen weil Sie noch da sind.

Aber ich denke, wir können hier diskutieren bis die Köppe rauchen und kommen zu keinem Ergebnis. ^^

Lass uns daher mit die Diskussion mit dem gemeinsamen Fazit: Wichtig ist das eine saubere Fehlerbehandlung da ist (und natürlich auch ausreichende Fehlervermeidungen eingebaut sind), die nicht nur einfach eine Meldung rausgibt und danach weiter macht als wenn nix gewesen wäre.

Wie man nun dahin kommt, dürfte wohl absolute Sache des eigenen Programmierstils sein. Zumindest solange bis MS nicht auf die Idee kommt VBA eine Standard-Routine für den Umgang mit Fehlern zu spendieren ... wie z.B. die hier mal erwähnte Exception-Behandlung von Java. *wink.gif*

Gruß

Rainer

 

Da dies dank Rainer & Josef nun der ultimative MOF-Thread zum Thema Fehlerbehandlung geworden ist *wink.gif*, darf natürlich ein Hinweis auf everythingaccess' Simply VBA Global Error Handler nicht fehlen:
http://www.everythingaccess.com/simp...or-handler.htm
(BTW: Mal die Referenzen auf der rechten Seite anschauen. *wink.gif* IMO wird Joachim auf der nächsten AEK auch seine Erfahrungen mit Waynes Tool zum Besten geben.)

Unter der Prämisse eines eingesetzten Simply VGEH könnte die man die Diskussion gleich neu aufrollen. *grins
Da der den CallStack auswerten kann (inkl. aller Fehlerzeilen), braucht es tatsächlich keine Fehlerbehandlung in Subprozeduren mehr - man kann alles aus der Hauptprozedur aus analysieren.

Ich erwähne den Simply VGEH auch deshalb, weil Wayne in den nächsten Wochen eine neue Version rausbringt, die komplett ohne zusätzliche DLL auskommt - natürlich mit seiner neuen Methode, den Binärcode in eine meterlange Daten-String-Variable zu packen. *entsetzt

Ciao, Sascha

 

Ich glaube, das würde gar nichts ändern *Smilie, weil auch der Simply VBA Global Error Handler nicht weiß, was er bei einem Fehler machen soll, der irgendwo entsteht und dann doch keine Rolle spielt.
Dafür muss man (nach meinen bisherigen Versuchen) auch bei Nutzung von Simply VBA Global Error Handler eine Fehlerbehandlung an den ausgewählten Stellen einbauen.
Eines ist aber praktisch an dieser Lösung: man erspart sich die allgemeinen Fehlerbehandlung für unerwartete Zustände, die immer bis ganz nach oben bzw. bis zur ersten Fehlerbehandlung abgebrochen werden können, weil man im Programmcode nicht damit gerechnet hat und somit auch keine Fehlerbehandlung existiert, die auf diese Fehler eingeht.
... also genau das Szenario, bei dem ich darauf aufmerksam machen wollte, dass die "VBA-übliche Fehlerbehandlung, welche den Fehler einfach aufhebt und dann weitermacht als wäre nichts passiert" ein Murks ist. *biggrin.gif*

mfg
Josef

 

Hi Josef,

Da du das "Gemurkse" nun mehrfach wiederholt hast: Ich stehe gerade in der Mitte zwischen deiner und Rainers Ansicht. *wink.gif*
Man kann das meiner Meinung nach nicht verallgemeinern; es kommt schon sehr drauf an, was in den Prozeduren steht.
Das Stoßen auf den Sachverhalt, dass hier ein Denkfehler vorliegen könnte, wenn man rasenmähermäßig Fehlerbehandlungen auf alle Prozeduren verteilt, ist absolut sinvoll.
Aber wenn die Subprozedur lang ist - kommt ja mal vor - und mehrere potentielle Fehlerstellen enthält, dann nervt die lapidare Meldung in der Hauptprozedur u.U. schon ziemlich und erfordert zusätzliche Nachforschungen.
Jedenfalls sind mir schon viele (VB6-)Projekte untergekommen, in denen der Autor die Subprozeduren ohne Fehlerbehandlung dastehen hatte und auftretende Fehler es dann nötig machten, den Code step-by-step zu debuggen, um auf den eigentlichen Fehlergrund zu kommen.
Für solche längeren Subprozeduren wäre dann dein bereits vorgeschlagenes Vorgehen günstiger, den Fehler abzufangen und deren Fehlerbehandlungen ihrerseits einen Fehler auslösen zu lassen.
...Oder eben den SVGEH einzusetzen.

Ciao, Sascha

 

Die lapidare Fehlermeldung bei meinem Vorschlag müsste natürlich den gesamten Aufrufpfad angegeben - also auch die Prozedur, in der der Fehler entstanden ist.

Mit Murks meine ich jene Variante, die einfach nach der Fehlermeldung weitermacht, als wäre nichts passiert, obwohl der Fehler nur angezeigt aber nicht behoben wurde und der Codeablauf komplett abgebrochen gehört.
Ich hatte das bei meinen Anwendungen auch einmal so, weil ich zu meinen Access-Anfangszeiten ebenso (ohne viel darüber nachzudenken), den üblichen Empfehlungen gefolgt bin und so eine Fehlerbehandlung in jede Prozedur einbaute:
Code:

Die Prozedur HandleError sorgte nur dafür, dass der Fehler angezeigt und protokolliert wurde, löste ihn aber nicht noch einmal aus.
=> Prinzip des Beispiels in Beitrag #29.

Und da ich mit diesem Murks genügend Probleme hatte, empfehle ich eben mit Nachdruck, das nicht ebenso zu machen. *Smilie

Wichtig: Das soll nur ein Beispiel für eine "Standard"-Fehlerbehandlung sein, die man (fast) überall hineinschreibt, wenn man auf keine speziellen Fehler reagieren will ... also im Prinzip der Anwendungsfall, für den man auch den Simply VBA Global Error Handler einsetzt.
Wenn in einer Prozedur bestimmte Fehler abgefangen werden, ist sowieso eine spezieller Code erforderlich.

mfg
Josef

 

\@ Sascha

Moment. ^^

In der Ansicht was Gemurkse in der Fehlerbehandlung ist, bin ich aber zu 100% Josef's Meinung:

Eine Fehlermeldung ausgeben und dann im Code nur die fehlerhafte Sub abbrechen aber die oberen Aufrufebenen machen weiter als wenn nix gewesen wäre, kann es eindeutig nicht sein.

Das Teil ist schon sehr genial.

Eigentlich nicht ... die grundsätzlich Thematik wie gehe ich mit einem fehler um, bleibt im Prinzip gleich ... nur der Code ändert sich, bzw. der Aufwand bei der Programmierung dürfte deutlich geringer sein.

@ Josef

Eigentlich nicht, du aktivierst das Teil bei Start und dann fängt es jeden Fehler ab ... egal was Du angibst, selbst bei On Error Resume Next in der Prozedur wird bei einem Fehler der aktivierte Error-Handler angesprungen.

Dein Prinzip konstant jeden Fehler zurück an die aufrufende Sub zu werfen kannst Du mit dem Teil auch problemlos realisieren ohne überalle eine Fehlerbehandlung zu haben: Einfach bei Ansprung des globalen Error-Handlers das Callstack-Object bemühen und auf den NextLevel gehen oder gleich ein OnErrorEnd für die ErrorEx.State Eigenschaft setzen lassen.

Im Prinzip könntest Du zu Beginn einer Prozedur einfach eine Konstante an eine globale Variable übergeben - z.B. aus einer Type-Auflistung - und dann wird beim Ansprung des Error-Handlers (das muss nicht mit On Error Goto XYZ gesetzt werden, sondern geschieht automatisch) einfach die ErrorEx.State-Eigenschaft auf den Inhalt der globalen Variable setzen und dadurch von Prozedur zu Prozedur entscheiden wie Du bei einem Fehler in der Prozedur weiter machen willst. Einen kompletten Abbruch der Folgecodes kannst Du z.B. mit OnErrorEnd setzen lassen.

EDIT:

Eigentlich nicht, wenn man sich ein wenig in die Object-Modelle einarbeitet ist schon deutlich mehr möglich mit dem Teil. Genial ist halt das man direkt im globalen Error-Handler auswerten kann ob und wenn welche Fehlerbehandlung in der fehlerhaften Sub festgelegt wurde und an Hand dessen bestimmen kann wie es dann nach einem Fehler weiter geht. Man muss das nicht mehr in der Prozedur selber erledigen.

Code:

Also quasi wenn ein Fehler auftritt und die Prozedur keine eigene Fehlerbehandlung hat dann den folgenden Code komplett abbrechen. Durch das CallStack-Object kannst Du Dir dann auch direkt in der globalen Fehlerbehandlung die komplette Aufruf-Hierachie zurück geben lassen ohne eine einzige Zeile Code in den Prozeduren direkt zu haben.

Bisher hat mich an dem Teil die Bezahlung per installierter Version gestört, aber gut die maximal 4,5 € pro installierter Version ist ja nicht die Welt. Zugegeben bin ich ernsthaft am Überlegen es einzubauen. Damit würde ich mir - ausser in den Fällen wo ich bestimmte Fehler gesondert handeln will - die Fehlerbehandlung sparen. Was Erstens den Aufwand bei der Programmierung massiv reduzieren würde und Zweitens den Code deutlich übersichtlicher machen würde.

Es ist im Prinzip wie mit dem zuvor genannten Java-Exception-Handling ... einbauen und alle Fehler werden abgefangen ohne das man im produktiven Code eine einzige Zeile Code schreiben muss.

Na ja, mal gucken und noch ein wenig rumtesten. *wink.gif*

Gruß

Rainer

 

Hallo Rainer,

den Aufwand bei der Programmierung sehe ich nicht. Mit den MZ-Tools ist das nur ein Mausklick.

Den Gewinn in der Übersichtlichkeit sehe ich dagegen auch. Das geht sogar so weit, dass ich nach der Anschaffung des Simply VGEH sämtliche "überflüssigen" Error-Handler entfernt habe. Bei einer Prozedur, die nur 3 Zeilen Nutzcode hat, hat sich dadurch die Zeilenanzahl auf unter ein Viertel gesenkt.

CU

 

Eigentlich nicht, du aktivierst das Teil bei Start und dann fängt es jeden Fehler ab

Wenn du einen Fehlercode besonders behandeln willst, musst du auch für den Simply VBA Global Error Handler eine Fehlerbehandlung in die Prozedur einfügen.

Wie meinst du das? Ich verstand die Erklärung von sebbl2 so, dass man bei Eclipse einen Try-Catch-Block erzwingen kann.
Das ist dann aber genau das Gegenteil von einer allgemeinen Fehlerbehandlung. *Smilie Oder meinst du nur die Ausgabe des Fehlers durch die Runtime?
Anm.: Wenn du z. b. unter C# eine Fehlerausgabe machst, kannst du auch ohne Zusatzprogrammierung die Entstehungsgeschichte eines Fehlers auslesen.
Die Umwege, um die Entstehungsgeschichte eines Fehlers zu erhalten, kenne ich nur von VB6/VBA. Bis nach außen abbrechen kann aber auch VBA bei unbehandelten Fehlern - nur bei der Access-Runtime wird das dann besonders lustig. *Smilie

mfg
Josef

 

\@ Thomas

Im Prinzip hast Du da natürlich Recht, aber die Codevorlage/n muss man ja auch erstmal erstellen und dann auch noch an das Einfügen denken - meine persönliche Nemesis ^^ - und dann auch noch überlegen ob Du Zusatzinformationen haben magst über Variablen-Inhalte oder obere Aufrufebenen.

Mit dem Teil ist das Recht easy ... einmal programmiert das bei einem Fehler nicht nur den Fehler und die Information zu der Prozedur, sondern auch alle Informationen zu allen oberen Aufrufebenen inklusive der kompletten Variablen-Zustände/Inhalte jeder Aufrufebene und fertisch.

Und auch die komplette (Standard) Logik was nach einem Fehler zu tun ist, kannst Du einmalig in dem Teil festlegen. Ansonsten muss ich immer noch ein paar Einstellungen am Aufruf des globalen Error-Handlers vornehmen um zu entscheiden what to do after Error.

Das glaube ich Dir aber sowas von auf's Wort. ^^

@ TOPIC-Thema

Je mehr ich drüber nachdenke, desto mehr gefällt mir die Variante Funktions-Aufbau wie eine API-Prozedure (Rückgaben von Werten in ByRef-Variablen zu speichern und die eigentlich Funktions-Rückgabe auf den Fehlerwert zu setzen) und dazu in Kombination den SimplyVBAErrorHandler.

Dann kann man da wo Fehler Verzweigungen in der Programmlogik auslösen sollen die Rückgabewerte hernehmen und ansonsten sich ausser bei der Behandlung von speziellen Fehlern keinen Kopf mehr um die Fehlerbehandlung machen. Damit wäre das Thema vergessene oder mal falsch eingestellte Fehlerbehandlungen ein Thema der Vergangenheit. ^^

Gruß

Rainer

 

\@ Josef

Musst man ja mit dem Teil eben nicht mehr zwingend machen. *wink.gif*

Das könnte man in vielen Fällen komplett in den globalen Error-Handler auslagern ... der weiss ja ohne Übergabe in welcher Prozedur aus welchem Modul der Fehler aufgetreten ist.

Das hätte dann den zusätzlichen Charme das man gleichartige Fehlerbehandlung zusammen fassen kann und nur noch an einer Stelle pflegen braucht.

Wie z.B. eine Fehlermeldung bezüglich nicht bestehender Verbindung zur Datenbank ... das machst Du nicht mehr in der Prozedur, sondern kannst das im globalen Error-Handler abhandeln ohne eine einzige Übergabe oder Ansprung dafür in der Prozedur programmiert zu haben.

Somit wärst Du ohne eine einzige Zeile im produktiven Code immer sicher, dass wenn mal ein Fehler wegen nicht bestehender Verbindung egal wo auftritt das dann das Programm automatisch versucht die Verbindung neu aufzubauen und wenn es klappt dann mit 'Resume' weiter macht und wenn nicht dann den weiteren Ablaufcode abwürgt.

Okay, dann habe ich da was falsch verstanden.

Genau das ist das Problem. *wink.gif*

Gruß

Rainer

 

Ja, ok, aber das wurde eigentlich so richtig erst im Verlauf der Diskussion sichtbar. *wink.gif* (Sonst wäre der Thread auch nicht so lang geworden.)

Mit dem SVGEH sehe ich das anders.
Da das ErrEx-Objekt beliebig steuerbar ist - im Gegensatz zum VBA-Err-Objekt - kann man die Fehlerbehandlung schon ziemlich umbauen:
- Den Callstack kann man an beliebiger Stelle erhalten und somit die Fehlerbehandlung in Subprozeduren reduzieren.
- Den Rückgabewert einer Subfunktion muss man nicht zwingend auswerten, sondern kann stattdessen direkt Variableninhalte über SVGEH-VariablesInspector auslesen - natürlich nicht die in der Subprozedur definierten und dann nicht mehr vorhandenen.
- Wohin die Fehlerbehandlung springen soll, kann man jederzeit festlegen und somit Verzweigungen zu verschiedenen Fehlerbehandlungen außerhalb der eigentlichen Prozedur anlegen und für verschiedenen Zwecke benutzen. (Etwa eine Routine für Engine-Fehler, eine für Recordset-Fehler, eine allgemeine, ...)

Wenn man das ganze Potential des SVGEH ausschöpft, dann weicht das Vorgehen zur Fehlerbehandlung schon vom normalen ab.

Ich gebe allerdings zu, dass ich ihn bisher noch nicht produktiv einsetzte, weil ich in neuen Projekten normal immer bereits vorhandene Module verwende/importiere - und die haben bereits meine üblichen Fehlerbehandlungsaufrufe eingebaut. Ich müsste also alle neu schreiben, was mir bisher zuviel Aufwand war.

Ciao, Sascha