Office: (Office 2003) Error handling

Hallo allerseits,

eine eher allgemeine Fragestellung. Da ich zum Ende meines Praktikums eine schöne große Access-Applikation erstellt habe bin ich nun dabei den Code noch etwas zu optimieren.

Während der Entwicklung hatte ich natürlich On Error GoTo 0 und habe die Fehler im Code behoben wie sie so kamen. An meinem letzten Arbeitstag ändere ich dann auf On Error GoTo hier Errorhandler der Funktion.

Allerdings macht man es sich damit ja etwas einfach, alle Fehler so an den User durchzureichen statt selber während der Programmlaufzeit auf Fehler zu prüfen und so habe ich angefangen, Stück für Stück meinen Code auf mögliche Fehler zu prüfen.

Am Beispiel einer Collection, aus der ich ein Item haben möchte:

Code:

Das ganze nimmt dann allerdings unmögliche Dimensionen an, wenn ich so aus einer einzelnen Codezeile (Set colRecord = colRecords.item(strRecordKey)) 10 mache und das mehrmals pro Funktion (und das dauernde an- und abstellen von Errorhandlern macht mich als Programmierer aus der Java- und C-Ecke auch ganz kirre).

Zwischenzeitlich hatte ich auch die Idee, generell VBA.Collection.item in eine eigene getItemFromCollection()-Funktion zu verpacken die dann jeweils das Fehlerhandling übernimmt und entweder das item oder Null zurückgibt, wenn es nicht in der Collection ist.

Aber irgendwie scheine ich damit über das Ziel hinauszuschießen und suche nun nach so einer Art 'best practices' zum Errorhandling in VBA. Ich habe recht wenige und dann sehr allgemein gehaltene Artikel zu dem Thema gefunden aber vielleicht hat ja noch jemand ein paar Tipps jeder Art (wie handelt man Errors sauber, welche Errors muss man besonders beachten, wie finde ich überhaupt heraus welche Errors durch welchen Code entstehen können?? etc...)

:)

 

Zu Deiner Frage: es ist nötig, alle Fehler abzufangen, die durch den DAU oder - allgemein gesagt - den U verursacht werden können und zusätzlich diejenigen, die durch Probleme in der Umgebung (Server, Drucker oder Netzwerk weg) ausgelöst werden können.
Das Programm sollte (möglichst) nie in einen undefinierten Zustand geraten.

Fehler im Code, die zu unkontrolliertem Verhalten führen, solltest Du spätestens in der Beta-Test Phase gefunden und korrigiert haben *wink.gif*

 

Soweit ist klar, aber das ist nun auch eine sehr allgemein gehaltene Antwort *Smilie

Nur leider kann niemand vorhersehen, welche Fehler alle durch DAU und System ausgelöst werden können, zumindest mit dem Error handling das VBA zur Verfügung stellt.

Das rein hypothetische Extrem wäre, nach jeder einzelnen Codezeile Err.Number auf alle überhaupt möglichen Fehlernummern zu prüfen (ich denke da an das schöne 227-seitige PDF von Microsoft in der die alle von 5 bis 32613 fein säuberlich aufgelistet sind). Aber das kann ja nicht der Weisheit letzter Schluß sein...

 

Hi,

ich wage mal eine provokante These:

Abzufangende Fehler darf nur das System machen (Platte voll, Netzwerk weg, ...). Wenn der User einen "Fehler" macht, dann nur, weil er zuwenig geführt bzw. zuwenig validiert wurde. *Smilie

Im Ernst: ein Fehler sollte eine Ausnahme sein (in .Net heißen sie ja auch Exceptions). Das heißt, es muss vorher regelbasiert geprüft werden, ob das Versuchte überhaupt gehen kann. Und das ist m.E. Sache der Validierung.

Und was die "Führung" angeht: es hilft dem User im Allgemeinen ungemein, wenn er nicht jederzeit alles machen kann, sondern nur das, was gerade angeboten wird (-> verfügbare Befehle managen). "Flexible" Systeme, die immer alles können, sind meist eher deorganisiert - der User kann von Hölzchen auf Stöckchen kommen und verzettelt sich.

Bondage and domination? Ja. In der Hinsicht schon *biggrin.gif*

 

\@ sebbl2

Im Prinzip musst Du Dir keinerlei Gedanken darüber machen wo und durch was Fehler entstehen ... Du musst einfach nur ÜBERALL, selbst in einer Prozedur mit nur 2 Zeilen, eine Fehlerbehandlung einbauen (und wenn es nur On Error Resume Next ist).

Natürlich solltest Du vorhersehbare Fehler in jeder Prozedur selber abfangen und behandeln, z.B. Null-Werte in Recordset-Feldern oder bei Eingabe vom User kommt ein ungültiges Datum wie z.B. 30.02.20xx.

Aber trotzdem solltest Du einen globalen Error-Handler haben, klassischer Aufbau wäre in etwa so:

Code:

Und dann in der Fehlerbehandlungs-Routine alles weitere veranlassen.

Komfortabler wird es wenn Du auch noch z.B. eine Enum-Konstante benutzt um pro Porzedur zu entscheiden wie es weitergehen soll ... z.B. Fehler in aufrufende Sub zurück werfen, Fehler in Tabelle/Log speichern und + Meldungs ausgeben + Resume Next oder Quit Procedure in der fehlerverursachenden Prozedur u.ä. Möglichkeiten.

Ich speichere in der Regel alle Fehler in einer Tabelle ab durch den globalen Error-Handler und biete dem User an nach der Fehlermedlung ein Fehlerprotokoll mit dem Error-Log per Email zu zu senden. Das hilft dann unheimlich Fehler in der Anwendung zu finden und zu korrigieren.

Gruß

Rainer

 

Dieser Aussage widerspreche ich grundsätzlich. Gedankenloses Programmieren kann man selber praktizieren, aber sicher nicht anderen empfehlen. Und mit On Error Resume Next sollte man sehr sparsam und gezielt umgehen. Einige scheinen ihr Auto aber nach Gehör einparken zu wollen.

Ein wesentlicher Gedanke ist bisher zu kurz gekommen: Vor der Fehlerbehandlung kommt die Fehlervermeidung.

Wenn ich ...
- eine Datei löschen will, die es gerade nicht gibt (If Dir(Datei) > "" ...),
- in einem Recordset, das keine Datensätze enthält, einen Wert abgreifen will (If Not rs.EOF ...),
- einer Stringvariablen Null zuweisen will (If Not IsNull(Variable) ...| Nz(Variable, "")),
so sind das vorhersehbare Probleme, die man vorher prüfen und behandeln kann und wo es somit zu keinem Fehler kommen sollte, der eine Fehlerbehandlung notwendig macht. Dieser Bereich liegt in voller Entwicklerverantwortung.

Fehler durch den Bediener kann man erheblich reduzieren, indem man den Benutzer führt (Martin sprach das an). Wenn der Bediener nur zwischen angebotenen gültigen Werten auswählen kann statt irgendwelchen kreativen "Mist" einzugeben, wäre das Fehlerpotenzial schon einmal deutlich eingeschränkt. Wenn der Bediener nur Aktionen und Auswertungen starten kann, wo alle benötigten Parameter zur Verfügung stehen, gibt es noch weniger Grund für Fehler.
Fehlbedienung und Fehleingabe durch einen Bediener sind nicht nur vorhersehbar, sondern schlicht zu erwarten. Also hat der Entwickler auch hier eine Verantwortung zur Vorbeugung.

Eine geeignete Fehlerbehandlung ist dann in jeder Routine trotzdem notwendig,
- um Fehler durch unbehandelbare Probleme aufzufangen (z.B. SendObject mit Löschen der Mail ohne Speichern/Senden),
- um Fehler aufzufangen, die durch Probleme entstehen, die trotz umfangreicher Tests unbeachtet geblieben sind (Beta-Phase noch nicht abgeschlossen),
- vor allem aber um unvorhersehbare Fehler abfangen zu können.

Diese Probleme aus dieser Gruppe sollten aber nur ausnahmsweise auftreten. Von einer Fehlerbehandlung pro Zeile kann dann aber keine Rede sein.

 

Bitte ... wenn Du mich zitierst, dann auch meinen Post zu Ende lesen.

Das entspricht ja genau Deiner Aussage bezügl. Fehlervermeidung und hat wohl auch nichts mit gedankenloser Programmierung zu tun.

Mir ging es nur um die Grundaussage das man in JEDER Prozedur eine Fehlerbehandlung braucht und nicht überlegen sollte ob man dort überhaupt eine braucht oder nicht ... das führt nämlich meistens zur der Fehlannahme dort können ja eh keine Fehler auftreten und deswegen brauche ich dort auch keine Fehlerbehandlung.

Aber lieber in einem Ein- oder Zweizeiler - wie z.B. eine Public Property die eine modulweite Var ausliest - ein On Error Resume Next als gar keine Fehlerbehandlung.

Gruß

Rainer

 

Wenn man etwas zum Prinzip erklärt, ist das eine starke Aussage. Einschränkungen sollten unmittelbar sichtbar gemacht werden. Von einer Einschränkung kann ich aber nichts lesen, auch bei mehrfacher Wiederholung nicht. Ich lese nur: Hauptsache Fehlerbehandlung, und alles ist gut. Da wäre sebbl2 wieder bei seinem eingangs beschriebenen Problem (= mehr Fehlerbehandlung als Kerncode).

Nö. Ein vermiedener Fehler ist nicht abzufangen oder zu behandeln.
Ein Fehler liegt vor, wenn das Error-Objekt reagiert. Daher sprach ich von Problemen, die man im Vorfeld behandelt oder umgeht.
Meine Aussage: Fehler-Vermeidungsstrategien sind etwas anderes als Fehler-Behandlungsroutinen und nicht zu ersetzen.
In meinen Augen wäre eine Programmablaufsteuerung über Fehlerbehandlung ein Unding, gerade in längeren Codes. Ausnahmen sind natürlich Routinen, wo das Auswerten des Fehlers Programm ist. Das wären dann aber i.d.R. kurze Prüfroutinen a la ...
Code:

Dem habe ich sichtbar zugestimmt und an keiner Stelle widersprochen - wobei aber z.B. bei der gezeigten Routine eine zusätzliche Fehlerbehandlung verzichtbar erscheint, wenn ich bei Funktionsaufruf sicherstelle, dass nur gültige Argumente übergeben werden.

 

On Error Resume Next kann übrigens auch eine sinnvolle Fehlerbehandlung sein, wenn sie im Verein mit etlichen Err.Clear und If Err.Number 0 daher kommt. *wink.gif*
Ist oft jedenfalls übersichtlicher, als alles im globalen ErrorHandler zu analysieren.

Aber zu Thema: Validierung, Plausibilitätsprüfung und Beta-Phase sind ja ok, aber mal ehrlich: Wer von euch macht das wirklich konsequent??
Wie sebbl bereits erwähnte, artet das zusammen mit der Fehlerbehandlung in enormen Aufwand aus. Wer so eine niet-und-nagelfeste Anwendung produzieren will, muss sicher mit dem 2-3-fachen Aufwand rechnen. Schön, wer Auftraggeber hat, die einem das dann bezahlen... *wink.gif*
Zumal es eine Illusion ist, dass man alle erdenklichen Fälle als Entwickler voraussehen könnte!

Ich sage frei heraus, dass ich diesen Aufwand normal auf's Nötigste reduziere und den User in einer ca. halbjährigen Testphase fleißig Fehler produzieren lasse. *grins
Die müssen dem nicht alle zu Gesicht geführt werden - bringt eh nix, außer der Erkenntnis, dass was nicht funktioniert hat. Ich entscheide deshalb in jeder Prozedur gesondert, wie ich Fehler an mein globales Fehlerbehandlungsmodul weiterleite. Die meisten werden mit einem "Do not show" als Parameter dorthin geschickt. Geloggt werden aber alle in einer Fehlertabelle im Backend.
Nach dieser Testphase ist dann meist weitgehend Ruhe, alles korrigiert, und ab und an tröpfeln noch ein paar Fehlerdatensätze rein.

Ciao, Sascha

 

Nun, um wie oben einen Collection-Eintrag zu verwenden, ist eine vorherige Prüfung, ob der auch wirklich da ist (falls er zwischenzeitlich wieder verschwinden kann), einfacher und kürzer als die gezeigte Fehlerbehandlung und erfordert auch keine mehrmonatige Testphase mit Protokollierung. Das ist vorhersehbar und gleich lösbar und war wohl die eigentliche Frage.

Selbstverständlich ist vorheriges Validieren Aufwand und schon deshalb auf Notwendiges zu begrenzen. Allerdings kann man mit einfachen Maßnahmen schon viele Fehler vermeiden:

Wenn das ungebundene Eingabefeld ein Format "Datum, kurz" erhält, würde eine solche Eingabe nicht angenommen. Dann könnte man sich bestenfalls darüber unterhalten, ob man dem User eine bessere Meldung als die accesseigene anbietet.

 

Was? Das in jede Prozedur eine Fehlerbehandlung rein muss/soll? Das ist keine starke Aussage sondern eindeutig Fakt ... zumindest wenn man mit Runtime-Umgebungen rechnen muss/will, die bei jedem unbehandelten Fehler ziemlich unelegant abschmieren.

Konsequente Fehlerbehandlung ist erste Regel weil man damit auch Fehlerquellen die man bei der Programmierung übersehen hat sauber löst ohne das gleich die DB abschmiert oder mit kryptischen Grey-Boxen antwortet.

Von daher: Ja, in erster Linie Fehlerbehandlung und in zweiter Linie Fehlervermeidung durch Validierung/Prüfung etc. und dann ist alles gut. Was ist an der Aussage jetzt falsch? Wer sich nur auf Fehlervermeidung verlässt wird irgendwann die ein oder andere böse Überraschung erleben. Und ich mag es halt absolut überhaupt nicht wenn sich User melden und mir mitteilen das meine DB abgeschmiert ist.

Was ist daran ein Problem? Wenn ich nur 1-2 Zeilen Kerncode habe und diesen Code an die globale Fehlerbehandlung anschliesse, habe ich halt mehr Fehlerbehandlung als Kerncode ... na und? Einfügen des Codes für den Anschluß an die globale Fehlerbehandlung durch MZ-Tools ist genau ein Maus-Click.

Wobei das Prinzip jede Eingabe zu validieren und zu prüfen um eine Fehlerbehandlung unnötig zu machen, dürfte wohl einiges mehr an Aufwand bedeuten.

Richtig und das gilt es eben zu vermeiden, soweit man es erkennen/erahnen kann. Und für die Fälle die man übersieht/an die man nicht denkt muss imho zwingend eine Fehlerbehandlung rein.

Meine Aussage: Man kann weder auf das eine, noch auf das andere verzichten. Selbst der beste Programmierer übersieht mal eine mögliche Fehlerquelle und dann braucht er eine saubere Fehlerbehandlung.

Kannst Du das wirklich zu 100% und unter allen Umständen? Ich wage zu behaupten das das eben nicht geht und es immer wieder selbst bei der besten Validierung und Prüfung zu Fehlern kommen wird.

Da stimme ich Dir zu 100% zu, habe aber auch nirgendwo was anderes behauptet. *wink.gif*

Ja ... und wie prüfst Du ob der gesuchte Eintrag wirklich in der Collection vorhanden ist? Soweit ich weiss gibt es keine Möglichkeit den String-Key einer Collection auf Exist zu prüfen ... nur die bekannte: Ansprechen und gucken ob Fehler oder nicht ... was ein klassisches Beispiel für das von Sascha angesprochene bewusste verwenden von On Error Resume Next, Err.Clear und if err.Number 0 ist. ^^

Okay, zugegeben ... dummes Beispiel. ^^

@ Sascha

Ich versuche es zumindest. *wink.gif*

Aber trotzdem kommen von den Usern immer wieder Fehler rein an die ich beim besten Willen nie gedacht hätte.

Gruß

Rainer

 

Hallo!

Ob überall eine Fehlerbehandlung stehen sollte, halte ich eher für Geschmacksfrage bzw. ist das von der Anforderung abhängig, ob man wissen will wo exakt ein Fehler aufgetreten ist. (Ich mache es aus dem Grund, weil ich wissen will, in welcher Aufrufreihenfolge von Prozeduren der Fehler aufgetreten ist.)

Bei einer Access-Runtime-Version ist es auch nur Pflicht, dass in der äußersten Aufrufprozedur eine Fehlerbehandlung enthalten ist, weil sonst die Anwendung abschmiert.
In den aus dieser äußeren Prozedur aufgerufenen Prozeduren muss nicht unbedingt eine Fehlerbehandlung enthalten sein, da in so einem Fall die Fehlerbehandlung der aufrufenden Prozedur wirkt.

Diese Forderung, dass überall eine Fehlerbehandlung enthalten sein muss, führt meiner Ansicht nach viel zu oft zu einer vermurksten Fehlerbehandlung, weil der Fehler nicht nach außen weitergereicht wird obwohl er nicht behoben wurde und in der aufrufenden Prozedur so weitergemacht wird, als wäre nichts passiert. So etwas halte ich für eine viel schlechtere Variante als wenn in den "Hilfsprozeduren" keine Fehlerbehandlung enthalten wäre und dann wenigstens der gesamte Ablauf bis zur äußeren Prozedur abgebrochen wird.

Beispiel: ErrorHandlerTest.zip + Kurzbeschreibung


mfg
Josef

 

Der Hinweis auf Prüfen des Collection-Eintrages war ein Fehler von mir und eine Verwechslung mit dem Dictionary. Beides hatte ich mir flüchtig angeschaut, verwende es aber noch nicht.

Wer hat denn davon gesprochen? (Nicht nur zum Lesen auffordern, sondern auch selbst tun!)
Mein Prinzip ist Fehler vermeiden (Primo) - da geht viel, wenn man die Augen aufmacht - und erst danach Fehlerbehandlung (die natürlich auch vorhanden ist).
Beim Parken des Autos habe ich übrigens das gleiche Prinzip. Ich vermeide lieber den Kontakt mit der Garagenwand statt zu Hammer und Lackspray und zu was noch zu greifen.

Von Fehlervermeidung war oben (#5) nicht die Rede, sondern nur von Fehlerbehandlung. Ich habe mal ein einfaches, dafür aber hoffentlich verständliches Beispiel zusammengestellt. Dabei kann man auch sehen, dass das Auffangen von Laufzeitfehlern (und Programmabstürzen) nicht alles ist. Wenn gerade ein Schreiben in Tabellen erfolgt, kann schon mal ein "unklarer" Zustand in den Daten auftreten. Die Varianten 2 und 4 zeigen dies:
Code:

 

\@ Josef

Okay, da hast Du natürlich Recht. Im Prinzip sollte es reichen in der aufrufenden Prozedur einen Fehlerbehandlung zu haben da der Fehler an die letzte Fehlerbehandlung zurück geworfen wird.

Wobei ich den Grund in jeder Prozedur eine Fehlerbehandlung zu haben nicht nur darin sehe das man Bescheid weiss wo der Fehler aufgetreten ist, sondern das die Fehlerbehandlung - und vor allem was passiert nach einem Fehler in der Prozedur selber - auch kontrolliert abläuft.

Gerade bei viel wiederverwendbarem Code wird es irgendwann nicht mehr möglich im Auge zu behalten welche der zig-Unterroutinen nun doch eine Fehlerbehandlung hat und welche nicht und dann wird es chaotisch.

Aber richtig, damit die DB nicht abschmiert muss nicht zwangsläufig in jeder Prozedur eine Fehlerbehandlung drinnen sein, die oberste Aufrufebene reicht aus.

@ ebs17

Du selber:

Was für mich soviel heisst, dass Du durchaus in jeder Routine erst überlegst ob dort eine Fehlerbehandlung nötig ist und durchaus auch mal auf eine Fehlerbehandlung verzichtest wenn Du glaubst dort gegen alle Fehler abgesichert zu haben. Oder habe ich Dich da falsch verstanden?

Ich versuche auch beim Auto fahren Unfälle zu vermeiden und umsichtig zu fahren und seit 20 Jahren hatte ich keinen Autounfall mehr. Aber trotzdem habe ich doch Wert drauf gelegt das mein neues Auto Airbags, ABS, ESP und sonstige Sicherheitsassistent an Bord hat und habe es Vollkasko versichert.

Daher baue ich in eine neue DB auch zu aller erst den globalen Error-Handler ein und gucke dann erst bei den Routinen das er am besten gar nicht zur Anwendung kommt, was aber quasi heisst das jede Routine ein eigene kleine "interne" Fehlerbehandlung/Ausnahmebehandlung beinhaltet ... und wenn es nur so einfache Dinge wie die Prüfung auf Null/Empty/Is Nothing o.ä. ist.

Ich denke Du verwechselst da was gewaltig:

Fehlerbehandlung einzusetzen heisst ja nicht zwangsläufig auf Fehlervermeidung zu verzichten.

Daher verstehe ich auch nicht so wirklich Deinen "Angriff" auf meine Aussage.

Ausser das ich die Fehlerbehandlung an erste Stelle setze - eben wie beim Auto, Sicherheitsausstattung muss passen - und dann im Code Fehlervermeidung betreibe und Du zuerst Fehlervermeidung betreibst und danach dann in manchen (wohl den meisten) Fällen Fehlerbehandlung einsetzt, sind wir uns ja im Prinzip einig: Code muss sauber programmiert sein und es gehört eine konsequente Fehlerbehandlung in jede Anwendung.

Ausser Du willst unterstellen das jeder der zuerst auf konsequente Fehlerbehandlung achtet, das tut weil er unsauber programmiert ... dann können wir natürlich noch stundenlang uns weiter die Köpfe heiß reden. *wink.gif*

Noch kurz zu Deinem Beispiel:

Klar durch Abfang durch Nz oder Prüfung auf Fehler 94 kann man Null und damit den Laufzeitfehler verhindern. Aber gerade im Zusammenhang mit dem dort erwähnten Datenzustand finde ich das Beispiel schlecht gewählt ... denn ein Variant-Wert kennt auch noch den Zustand Empty und den Inhalt Leer.

Beides führt zwar nicht zu einem Laufzeitfehler, aber beides dann in den Beispielen zu einem nicht gewünschten Datenzustand führen ... gerade Empty würde ja bei Recordsets als Null interpretiert werden, was dann wiederum möglicherweise bei der Ausführung von Update zu einem Problem führt.

Gruß

Rainer

 

Hallo
@Rainer
Dein letzter Beitrag spricht mir aus dem Herzen*biggrinlove