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.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:
