André Minhorst, Duisburg
Es gibt wohl keine Anwendung, die absolut fehlerfrei ist. Selbst gestandene Softwareprodukte mit einer riesigen Benutzerschar wie beispielsweise die Microsoft Office-Produkte verschwinden schneller wieder vom Markt, als es bis zur Behebung aller vorhandenen Fehler dauert. Hier und auch bei selbst gebauter Software wie etwa einer Access-Datenbankanwendung gilt in jedem Fall die Maxime: Nur entdeckte Fehler können behoben werden – und bei deren übermittlung hilft die folgende Lösung.
Den herkömmlichen Weg der Softwareentwicklung (ausgenommen die Wartung) kann man mit folgender Kette beschreiben:
In den meisten Fällen schleichen sich während der Softwareentwicklung noch einige Iterationsschritte ein, in denen neue Ideen des Auftraggebers einfließen und änderungen des Pflichtenheftes und der anschließenden Softwareentwicklung bewirken (gut) oder die stillschweigend einfach in das Produkt eingearbeitet werden (schlecht, da zwingend Abweichungen zwischen Pflichtenheft und Produkt entstehen).
Auch das Testen des Produktes durch einen möglichst neutralen Tester kann unter Umständen – etwa bei gröberen Fehlern – noch bis zum Pflichtenheft rückwirken. Selbst der gewissenhafteste Test wird aber in der Regel nicht alle denkbaren Anwendereingaben abfangen; somit ergeben Einführungsphasen und eventuell sogar Produktivphasen noch Fehler, die Nachbesserungen erforderlich machen.
Je mehr Fehler in dieser Phase auftauchen, desto schlimmer: Erstens ist es immer unbefriedigend, wenn der Anwender Fehler aufdeckt, zweitens kann dieser in der Regel nur vage Hinweise auf die Entstehung des Fehlers geben, geschweige denn eine Beschreibung zu dessen Reproduktion liefern.
Der vorliegende Beitrag will Ansätze für eine angemessene Fehlerbehandlung und -dokumentation für diese Phase im Lebenszyklus eines Softwareproduktes liefern. Daher stellen die nachfolgenden Kapitel eine Möglichkeit vor, wie eine Anwendung bei Auftreten von Fehlern den Anwender in angemessener Weise davon in Kenntnis setzt und gleichzeitig eine für den Hersteller nutzbare Fehlerbeschreibung ausgibt.
Das bedeutet erstens, dass die Anwendung den Benutzer nicht mit irgendeiner von Access selbst generierten Fehlermeldung abspeist, sondern ihn einfacher und verständlicher Form vom Auftreten eines Fehlers in Kenntnis setzt und ihn darum bittet, die notwendigen Informationen zur Behebung des Fehlers an den Hersteller zu schicken.
Diese Informationen – und das ist der zweite Punkt – soll die Anwendung in einer leicht zu versendenden Form ausgeben. Im vorliegenden Fall soll das eine Textdatei mit dem beziehungsweise den aufgetretenen Fehlern sein.
Die Fehlerbeschreibungen sollen mindestens die Angabe des Moduls, der Routine und der Zeile enthalten, die zum Fehler führten. Dazu gehört, dass jede Zeile der Anwendung nummeriert ist. Wie man das ohne viel Aufwand bewerkstelligt, erläutert ein eigenes Kapitel.
In vielen Fällen kann es auch hilfreich sein, wenn die Fehlerbeschreibung zusätzlich Informationen über aktuell in der jeweiligen Routine verwendete Variablen enthält. Ob und wie ausführlich diese Informationen sein sollen, ist von Fall zu Fall zu entscheiden.
Wie bereits erwähnt, sollte jede einzelne Prozedur eine Fehlerbehandlung enthalten. Der Grund ist, dass man nur so sicherstellt, dass nicht doch irgendwo ein Fehler auftritt, der zu einer nicht gewünschten systemgenerierten Fehlermeldung führt.
Dazu gehört auch, dass Sie nicht nur die üblichen Fehlermeldungen behandeln, die im Code auftreten und die der Debugger in der Regel zuverlässig entdeckt und mit Fehlernummer und Beschreibung ausgibt.
Es gibt einige Fehler, die Access anders behandelt, soweit der Entwickler keine speziellen Maßnahmen trifft. Dazu gehören etwa Formularfehler, die nicht unbedingt auf die im zugehörigen Formularmodul enthaltenen Routinen zurückzuführen sind, oder Fehler, die beim Ausführen von SQL-Anweisungen ohne Fehlerbehandlung auftreten. Hier sind spezielle Maßnahmen vonnöten, deren Beschreibung ebenfalls ein eigenes Kapitel einnimmt.
Formulare liefern bei Fehleingaben Fehlermeldungen zurück, die normalerweise aussagekräftig genug sind, um dem Benutzer den Fehler in angemessener Weise aufzuzeigen. Ein schnell nachvollziehbares Beispiel ist ein Textfeld, dessen Eigenschaft Format beispielsweise auf Allgemeine Zahl eingestellt ist (Abb. 1).
Abb. 1: Auftreten eines Fehlers durch falsche Formulareingaben
Gibt der Benutzer hier etwas anderes als eine Zahl ein, also beispielsweise eine Buchstabenfolge, erscheint die Fehlermeldung Sie haben einen Wert eingegeben, der für dieses Feld nicht zulässig ist. Diese Fehlermeldung erscheint auch, wenn man den Datentyp eines eventuell an dieses Feld gebundenen Tabellenfeldes verfehlt.
Abhilfe schafft ein Zweizeiler. Mit der folgenden Prozedur, die durch die Ereigniseigenschaft Bei Fehler des Formulars ausgelöst wird, findet der Benutzer eine alternative Fehlermeldung vor:
Private Sub Form_Error(DataErr As _ Integer, Response As Integer)
MsgBox "Es ist ein Fehler " _ & "aufgetreten. (" & DataErr & ")"
Response = acDataErrContinue
End Sub
Die erste Anweisung gibt eine Meldung mit einem kurzen Hinweis und der Fehlernummer aus, die zweite unterbindet die herkömmliche Fehlermeldung.
Dazu verwendet die Prozedur den Parameter DataErr, der die Fehlernummer enthält, sowie den Parameter Response, dem man eine der beiden Konstanten acDataErrContinue (herkömmliche Fehlermeldung auslassen) oder acDataErrDisplay (Standardwert) zuweist.
Natürlich sind Eingabefehler des Benutzers kein Grund, Einträge in eine Fehlerprotokolldatei vorzunehmen und diese gegebenenfalls auch noch an den Hersteller zu schicken – das sollten Sie sich für andere Kaliber aufsparen. Eingabefehler sollten Sie besser durch eine entsprechende Validierung beim Eintreten des Ereignisses Vor Aktualisierung verhindern.
Mit der On Error-Ereigniseigenschaft beugen Sie allerdings unterwarteten Fehlern vor und können mit Hilfe entsprechender Maßnahmen den Benutzer und den Hersteller angemessen informieren. Wie diese Information genau aussieht, erfahren Sie in Kapitel 4.
Berichte wie Formulare behandeln
In Berichten sieht es ähnlich aus. Es kann selbst in der ausgefeiltesten Software vorkommen, dass der Anwender mit unerwarteten Eingaben für nicht weniger unerwartete Fehler sorgt.
Bei Berichten sind die Fehleingaben zwar schon vorher da, aber vermutlich nicht entsprechend verhindert worden. Um auf Nummer Sicher zu gehen, macht man sich auch hier die Ereigniseigenschaft On Error zu Nutze.
Nachdem Sie nun wissen, wo überall eine Fehlerbehandlung hingehört, benötigen Sie noch die Details zu deren Inhalt und Erscheinungsbild.
Um den Kunden beziehungsweise Benutzer Ihrer Datenbank mit möglichst wenig Umständen zu belasten (Was haben Sie genau gemacht? Wo ist der Fehler aufgetreten? Welche Fehlermeldung gibt es? Können Sie mir einen Screenshot von der Ansicht machen, in der die gelb markierte, fehlerhafte Zeile zu sehen ist?), beschaffen Sie all diese Informationen weitgehend automatisiert.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo