Office: (Office 2003) Error handling

[OT]

Manchmal wird auch nur versucht zu programmieren. *biggrin.gif*
Ich schreibe auch manchmal auf gut Glück SQL-Code und hoffe, dass ich ich die richtige Logik erwischte ... ist das dann eine spezielle Form von Testgetriebener Entwicklung? *Smilie

mfg
Josef

 

Damit bringst du ja fast mein Weltbild ins Wanken o))

 

Da habe ich ja eine schöne Diskussion losgetreten - es scheint also so etwas wie allgemein anerkannte best practises für VBA kaum zu geben *Smilie

Auch ein Grund warum ich Java bevorzuge, wenn etwas einen Fehler auslösen kann wird eine Exception geworfen und mit der richigen Einstellung in der IDE wird man gezwungen, alle Exceptions zu behandeln bevor der Code läuft. Anfangs unbewusst habe ich dieses try catch finally Konstrukt mit dem Code im ersten Post dann ja auch nachzubilden versucht (das Analogon zu finally, ein GoTo Cleanup_PopulateSubform, habe ich der Übersicht halber rausgelassen). Und wenn ich es recht gelesen habe ist man in VB.NET den gleichen Weg über Exceptions gegangen, gemischt mit der C-Philosophie, einen Rückgabewert zu prüfen.

Aber ausreichend Anregungen habe ich hier gefunden, danke also dafür. Für das jetzige Projekt zu spät, noch alles umzusetzen aber im Test durch die Anwender läuft meine Anwendung inzwischen fehlerfrei. Letztendlich also das was Sasche sagte:

 

Womit wir wieder bei der Frage wären ob untere Aufrufebenen überhaupt Laufzeitfehler abfangen/aufheben müssen?

Das Deine Variante der Fehlerbehanldung das Laufzeitfehler wieder zur aufrufenden Sub zurück geworfen werden wesentlich sinniger ist als die meisten sog. Fehlerbehandlungen brauchen wir nicht zu diskutieren.

Aber ich denke einfach nicht das das der Weisheit letzter Schluß ist/sein kann.

Für meine Begriffe sind auch mit dieser Variante noch zuviele Nachteile verbunden:

1. Man kann in der Sub in der der Fehler aufgetreten ist nicht mehr aufräumen, also z.B. Recordsets explizit mit Close schliessen und zerstören ... was bei zu häufigem Vorkommen während der Laufzeit wieder zu Problemen mit dem internen Objekthandling von Access führen kann.

2. Man muss einen Teil der Programmlogik auf den Error-Handler der aufrufenden Sub verlegen, da ja dort die Fehler aus den aufgerufenen Subs ankommen. Und wenn kein Abbruch erfolgen soll muss man wieder Einstiegspunkte in der Sub schaffen auf die zurück gesprungen werden kann.

3. Aus Programmlogik-Sicht muss eben nicht alles was auch einen Laufzeitfehler produziert wirklich ein Fehler sein. Sondern kann auch durchaus einer normalen Zustands-Prüfung entsprechen ... wie eben auch Dein Beispiel mit der getrennten Server-Verbindung.

Rein aus diesen Gründen arbeite ich eben sehr oft lieber mit einer Prüfung der Rückgabe in der oberen Aufrufebene um dann dort aus Programm-Logik-Sicht zu entscheiden was nun zu tun ist ... komplett abbrechen oder weiter machen oder woanders weiter machen oder was auch immer.

Diese Fortsetzungs-Logik kann man in keine untere Aufrufebene implementieren, weil man ja nie weiss wie die Fortsetzungslogik beim Aufruf aus einer anderen Sub sein soll.

Grundsätzlich würde mir eine untere Aufrufebene nach folgendem Strickmuster (Achtung, nur grober Beispielcode) von daher wesentlich besser gefallen:

Code:

Und in der aufrufenden sub dann so:

Code:

In meinen Augen wäre das der sinnvollste Umgang mit Fehlern in unteren Aufrufebenen.

Aber nur meine bescheidene Sicht der Dingen. *wink.gif*

Natürlich, nur nennt man es heute Test Driven Development ... wie Josef schon so treffend formulierte. *g*

Nein, das ist nicht eine spezielle Form, sondern das ist Test Driven Development ... du sollst ja falschen Code programmieren, damit Du weisst was falsch ist um daraus zu erkennen was anders zu machen ist.

So mache ich das immer ... einfach mal programmieren/schreiben/tippseln und gucken was schief läuft ... der sicherste Weg zu sicherem Code. *lach*

Gruß

Rainer

 

Woher weiß die Java-Entwicklungsumgebung, was einen Fehler auslösen kann?

Das mit Try-Catch-Finally kannst du im Prinzip auch in VBA umsetzen. Es ändert aber nichts an der Thematik, was man im Fehlerfall damit macht.

Wenn du dir den Code in Beitrag #29 ansiehst, entspricht das im Prinzip einem Try-Catch-Finally-Gerüst.
Code:

Im Prinzip könntest du auch mehrere solche Blöcke einbauen.

Code:

Als besonders übersichtlich empfinde ich das allerdings nicht. *Smilie

Eine andere Variante, die für mich noch schlechter lesbar ist, da ich bereist für den Standardablauf das goto finally beachten muss:
Code:

mfg
Josef

 

\@Rainer:

Warum sollte man nicht aufräumen können?

Code:

Wo ist dabei das Problem? Das musst du doch bei den eingebauten VBA-Funktionen ebenso machen.

Bei erwarteten Fehler ist da sowieso etwas anderes.
Bezüglich Server-Verbindung betrachte ich das aber durchaus als Ausnahmezustand, den ich ich nicht bei jeder Funktion prüfen will, da ich normalerweise schon davon ausgehe, dass der User das Netzkabel eingesteckt lässt und ich auch im Regelfall davon ausgehen, dass die Admins den Server nicht abdrehen. Das Vorhandensein eines Server vor jedem Datenzugriff zu testen finde ich übertrieben (Ausnahme wäre hier eine instabile Web-Verbindung o. ä.). Ich prüfe z. B. auch nicht, ob eine Tabelle in der DB vorhanden ist, wenn ich im FE darauf zugreife und das eine Tabelle ist, die zur Grundkonfiguration des BE gehört. Sollte sie dann doch einmal nicht vorhanden sein, kommt es eben zu einem Laufzeitfehler, der dann in meinen Anwendungen bewirkt, dass ich die gesamte Aufrufhierarchie beende. Ich baue in meine Anwendungen nicht ein, dass sie dann selbst die Tabelle erzeugen, da ich sonst einen möglichen DB-Fehler übergehe und den DB-Admins die Chance nehme, den Fehler rechtzeitig zu erkennen, um ein zeitnahes Backup einzuspielen.

[OT]

Bist du sicher, dass das eine Forderung von TDD ist?

 

\@Josef P.

Welche Art von Exceptions ein Aufruf auslösen kann wird durch die API definiert. Als Beispiel die get-Methode des Array-Objekts:

http://download.oracle.com/javase/1....g.Object, int)

Verwendet man diese Methode also in einem try-Block kann man drei verschiedene Arten von Exceptions catchen. Es bleibt einem natürlich selber überlassen, vorher Fehlervermeidung zu betreiben (bspw. die Funktion nicht mit null aufzurufen und so die NullPointerException von vornherein auszuschließen), oder die Exception weiterzureichen oder sie ganz zu ignorieren.

Fehlt mir bei VBA auch sehr - oder vielleicht hab ich es einfach noch nicht gefunden, eine Auflistung, welcher Aufruf welche Fehler verursachen kann. So bin ich praktisch darauf angewiesen, dass jeder Fehler der für mich relevant ist einmal auftritt, bevor ich ihn sauber behandeln kann.

 

Verstehe ich dich richtig: Sobald über die Schnittstelle definiert ist, dass Fehler ausgelöst werden, zwingt dich die IDE dazu (bei aktivierter Einstellung), dass du einen Try-Block verwenden musst. Das finde ich praktisch.
Bei C# mit Visual Studio kenne ich so eine Option nicht - sie ist mir zumindest bisher noch nicht aufgefallen.

Es gibt in VBA auch wenig unterschiedliche Fehler-Klassen. Im Prinzip läuft innerhalb VBA alles nur über das Err-Objekt. (Nur ein einige COM-Bibliotheken bringen noch eine eigene Error-Auflistung mit.)

BTW: Versuch lieber gar nicht VBA mit Java, C++, C#, VB.net o. ä. zu vergleichen, das deprimiert dich nur. *biggrin.gif*


mfg
Josef

 

Natürlich nicht ... schreibe das nächste Mal IronieOn/IronieOff als Tags dazu. *wink.gif*

Sorry, falsch ausgedrückt ... man kann aufräumen, muss das dann aber zweimal schreiben. Einmal beim normalen Verlassen und einmal bei Eintritt in den Err_Handler-Teil. Wie Du, vermeide ich gerne doppelte Arbeit ... ich hasse es zweimal exakt das Gleiche in einer Sub schreiben zu müssen (okay, passiert aus Bequemlichkeitsgründen doch schonmal ... aber hier wäre es ja vorsätzlich ^^).

Nö ... nie. ^^

Erkennbare Fehlerquellen, falsche Rückgaben/Eingaben, nicht vorhandene Files/Objekte usw. behandele ich - soweit sinnvoll machbar und das ist es in fast allen Fällen - in der Programmlogik und nicht im Error-Handler.

Die Fehlerbehandlung fängt nur Fehler ab mit denen ich mal überhaupt nicht gerechnet habe.

Und das eine aufgerufene Sub mal einen ungültigen Wert zurück liefert ist für mich keine Sache der Fehlerbehandlung an sich sonder ein Fall für die Prüfung innerhalb der Programmlogik.

Werfe ich aber jeden Fehler zurück, muss ich eben genau diesen Teil der entscheidet wie es bei ungültigen Werten aus aufgerufenen Subs weiter geht zusätzlich noch in die Fehlerbehandlung einbauen. Wie gesagt immer davon ausgehende das es ungültige Werte im Sinne von Fehlermeldungen gibt und ungültige Werte im Sinne der Programmlogik.

Wo ist da das Problem? Wie ich Dich kenne hast Du ja eh die Datenzugriffe und den Aufbau der Connection gekapselt. *wink.gif*

Okay, da ist wohl wieder der Punkt der unterschiedlichen Nutzer der DB. Bei mir kommt es nicht vor das ein Fremder Tabellen und Strukturen im BE verändern kann. D.h. es gibt es nicht das es eine Tabelle nicht gibt, ich habe Sie ja selber dorthin gepackt und ausgeliefert.

Gruß

Rainer

 

Wenn ich mir meine Fehlerbehandlungen vorstelle, fällt mir eigentlich keine Fall ein, wo ich damit Probleme hätte.
Das liegt aber vermutlich auch daran, dass ich realtiv kleine Prozeduren erstelle, in denen nur wenig aufzuräumen ist.
Anm.: mit Aufräumen meine ich Close ... das Setzen auf Nothing ist bei Prozedurvariablen in der Fehlerbehandlung eher eine Fleißaufgabe, da beim Verlassen der Prozedur sowieso die Referenz entfernt wird.

Nö ... nie. ^^

Erkennbare Fehlerquellen, falsche Rückgaben/Eingaben, nicht vorhandene Files/Objekte usw. behandele ich - soweit sinnvoll machbar und das ist es in fast allen Fällen - in der Programmlogik und nicht im Error-Handler.

Und wo ist nun der Unterschied einer VBA-Funktion zu einer eigenen Hilfsfunktion? Für mich ist das das gleiche Prinzip, weil jede dieser Funktionen eine bestimmte Aufgabestellung kapselt. Wenn ich so eine Funktion einsetze ist mir das egal, ob das eine VBA- oder eine eigene Funktion ist, da ich nur an deren Ergebnis interessiert bin.

Wollen wir wetten, dass ich in deinem BE eine Tabelle löschen oder verändern kann?
Wenn ich das aber mache, weil ich die Daten auch für eine andere Anwendung nutzen will und dann deine Anwendung dauernd mit Fehlermeldungen schließt, bin ich selbst schuld. Ich würde zumindest nicht erwarten, dass deine Anwendung dann über die Fehlerbehandlung die Tabelle wieder herstellt.

mfg
Josef

 

Genau so ist es - macht man auch nicht immer, gerade wenn man nur 'quick n dirty' irgendwas zum ausprobieren machen oder nicht jede noch so unwahrscheinliche Exception berücksichtigen will aber wenn es dann daran geht die Anwendung releasefertig zu machen sollte es keine unbehandelten Exceptions mehr geben. Ich spreche dabei übrigens von der Eclipse IDE, ob alle Java-IDEs das anbieten kann ich nicht sagen.

Mit welcher Aufruf welche Fehler verursachen kann meinte ich schon ausschließlich das Err-Objekt und da aber welche Err.Number alle auftreten können. Bspw. Aufruf Len(str as String) kann Err.Number 1234, 4530 und 3052 verursachen.

Da hast du recht *Smilie ich hatte vor ca. zwei Jahren schon einmal 8-10 Wochen lang mit VBA (damals in Excel) herumprogrammiert und das hat einen so prägenden Eindruck hinterlassen, dass ich binnen zwei Jahren alles damals gelernte wieder vergessen (verdrängt?) habe *biggrin.gif*

 

Ich kenne keine Quelle, wo man das für die VBA-Funktionen nachlesen kann.
Am ehesten noch in der MDSN, aber auch dort wüsste ich nicht wo das zu finden wäre. Ich vermute eher, dass so eine Auflistung gar nicht verfügbar ist.

 

Das sagst Du, ich bin da noch immer anderer Meinung.

Hatte heute erst wieder den Fall das ich über ein Formular ein anderes Formular aufgerufen habe (kein UFO) und in das aufrufende Formular die Instanz-Referenz übernommen habe um auf Ergeinisse des aufgerufenen Formulares zu reagieren ... unter anderem auch auf ein eigenes Ereignis was ich beim Schliessen des aufgerufenen Formulares feuern lasse.

Und dann wunderte ich mich dumm und dämlich wieso das aufgerufene Formular sich nicht schliessen liess wenn ich das Aufrufende Formular zuvor geschlossen habe. War ganz einfach ... obwohl geschlossen reagierte das aufrufende Formular noch auf das Ereignis des aufgerufenen Formulares.

Das Problem war erst behoben, nachdem ich im Unload-Ereignis des aufrufenden Formulares die in einer Modul-Variablen gehaltene Instanz-Referenz explizit per set Variable = Nothing zerstört habe.

Soviel zum Thema zuverlässiges zerstören von Objekten nach Beendigung der Prozedur-Instanz. *wink.gif*

Okay, das sehe ich völlig anders. Hilfsprozeduren erledigen für mich Aufgaben die zwar durchaus einer eigenen Logik folgen können, aber ansonsten völlig unabhängig von der Logik der aufrufenden Sub sind.

Damit bleiben Sie autark und können egal wo immer wieder verwendet werden. Ähnlich wie API's ... sie erledigen Ihren Job und geben zurück ob korrekt ausgeführt oder nicht, aber sie beinhalten keine eigene Logik nach dem Motto wenn das dann muss das getan werden und wenn das dann muss das getan werden.

Die Logik ist für mich dann in den Projekt bezogenen VBA-Prozeduren drinnen die entscheiden dann wie was zu behandeln ist.

Aber gut, das ist sicher Ansichtssache, bzw. Sache des eigenen Programmierstils. *wink.gif*

Wenn Du den Passwortschutz von Access 2007 knacken kannst, dann ist es natürlich möglich ... aber ehrlich, solche Fälle will ich gar nicht in der Fehlerbehandlung behandeln ... das soll das FE ruhig sauber abschmieren. *wink.gif*

Gruß

Rainer

 

Habe Sie wieder gefunden die Fehler-Auflistung. *wink.gif*

Nachstehend die Auflistung aller möglichen VBA-Fehler in Access, aber ka ob die vollständig ist.

http://www.adad95.de/adad95doku/01-E...rmeldungen.htm

Gruß

Rainer

EDIT: Habe gerade gesehen das es doch nicht die Seite ist die ich gesucht hatte, aber immerhin ein Anfang allerdings fehlen auf der URL die ganzen Fehlermeldungen aus den negativen Bereichen.

 

Cool. Ich schaffte es bisher noch nicht, dass ich zum Reagieren auf Ereignisse eine Prozedurvariable verwenden konnte.
Und damit wir mal wieder nicht von unterschiedlichen Dingen schreiben: unter Prozedurvariable verstehe ich eine Variable, die in einer Prozedur deklariert wurde.

Wo ist da nun der Unterschied zu meiner Aussage, dass die Hilfsprozedur ihre Aufgabenstellung kapselt und wie eine VBA-Funktion arbeitet?

Und was schrieb ich dazu? Hatte ich geschrieben, dass das FE, das abfangen soll?