Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 5/2004.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Professionelle Fehlerdokumentation

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.

Testen und finden

Den herkömmlichen Weg der Softwareentwicklung (ausgenommen die Wartung) kann man mit folgender Kette beschreiben:

  • Lastenheft (Anforderungen aufnehmen)
  • Pflichtenheft (Produkt spezifizieren)
  • Softwareentwicklung
  • Softwaretest
  • Abnahme
  • 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.

    Fehlerbehandlung für alle

    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.

    Fehler in Formularen und
    Berichten

    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.

    Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

    Sind Sie Abonnent?Jetzt einloggen ...
     

    Kompletten Artikel lesen?

    Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

    E-Mail:

    Verwandte Beiträge:

    Fehlersuche und –behandlung mit Access

    Fehlerverwaltung mit Online-Komponente

    VBA-Fehlerbehandlung revolutioniert

    © 2003-2015 André Minhorst Alle Rechte vorbehalten.