Wie viel Mühe gibt ihr euch Fehler abzufangen?

[Popov]

Vielleicht wurde die Frage schon gestellt, aber ich stelle sie mir immer wieder. Wann ist der Guten genug?

Beispiel: ihr legt einige Daten (Mehrzahl von Datum) irgendwo in Stringform ab, z.B. in einer Ini. Jetzt wollt ihr die Daten incl. dazugehörige Informationen in ein ListView anzeigen. ListView schluckt Strings, also muß das Datum nicht überprüft werden. Nun stellen wir uns vor ein Witzbold ändert ein Datum in Textform von 01.09.2008 in 01.09.200F (Beachtet das F).

Nun stellt sich die Frage wie viel geprüft werden muß. An dieser Stelle wäre es egal, denn die Daten sollen hier nur angezeigt werden. Also einfach schlucken und unsinnige Daten anzeigen und den User selbst merken lassen? Überprüfen, aber ohne Hinweis weglassen, da falsches Datum? Oder bei jedem falschen Datum eine Fehlermeldung ausgeben?

An einer anderen Stelle werden die Daten verarbeitet. Hier muß das Datum stimmen. Wie hier reagieren? Falsche Daten ignorieren? Oder bei jedem falschen Datum eine Fehlermeldung, auch wenn das bedeutet, daß es 1000 falsche Daten sind und der User eine halbe Stunden Fehlermeldungen klicken muß? Oder einfach einen Zähler einbauen und wenn der nach dem gesamten Ablauf größer Null ist, informieren?

Wie gesagt, das mit den Daten ist nur ein konstruiertes Beispiel, also nicht klugscheißen und meinen, daß man Daten nicht als Textform speichert. Es geht nur drum wann man Fehler anfangen sollte. Ich hab immer das Gefühl, daß ich zuviel prüfe. Etwa die hälfte des Programms besteht bei mir in der Regel aus Abfangroutinen. Sogar da wo ich es nicht machen müßte, mache ich es. Bevor ich ein Text in ein TMemo lade prüfe ich zumindest ob die Datei vorhanden ist. Nun ob ich eine Fehlermeldung ausgebe oder das System ist eigentlich egal, aber ich mache es trotzdem.

Aber wie sehr sollte man den User vor sich selbst schützen? Sollte man alles immer überprüfen? Auch bei Daten die der User nicht manipulieren sollte? Sollte man es einfach verarbeiten und wenn einer die Daten manipuliert hat, dann ist er selbst schuld und wenn das Ergebnis falsch ist? Oder sollte man die User vor sich selbst schützen und alles überprüfen und abfangen?

[taaktaak]

Zitat:

Oder sollte man die User vor sich selbst schützen und alles überprüfen und abfangen?

- nach Möglichkeit JA!

[mkinzler]

Ich würde den Benutzer nur Dinge ändern lassen (Ini) welche er ändern können muss.

[alcaeus]

Zitat von Popov:

Oder sollte man die User vor sich selbst schützen und alles überprüfen und abfangen?

Da ich im Web-Bereich taetig bin, muss ich per Definition eh alles was an Daten herkommt als Angriffsversuch werten. Dass man das teilweise nicht so "eng" sehen muss, duerfte aber auch klar sein.

Fakt ist, wenn du Daten laedst und sie anzeigst, muesstest du sie eigentlich nicht ueberpruefen. Wenn du sie aber verarbeitest (und sei es nur weil der Benutzer sich nach 10 Minuten gucken dazu entschieden hat) musst du sie auf Korrektheit pruefen und ne Fehlermeldung werfen, falls was nicht passt. In dem Fall wird sich der Benutzer aber fragen, was da los ist; schliesslich hat er die Daten ja schon zu Gesicht bekommen, also muss doch alles passen, oder?

Mein Tipp: pruef die Daten beim Laden. Wenn was nicht passt, zeig den Datensatz an und gib dem Benutzer die Option, den Datensatz zu korrigieren oder zu verwerfen. Wenn er es ernst meint, wird er das Datum das er vorhin geschrottet hat (bzw. nicht geschrottet hat, Benutzer wuerden sowas ja nie machen ) wieder korrigieren; wenn nicht verwirft er den Datensatz und du kannst normal weiterarbeiten.

Greetz
alcaeus

[tr909]

also ich habe z.b. ein paar kleiner progs, mit denen ich daten aus ne Textdatei einlese um sie dann in ne Datenbank zu schreiben. Wenn da ein Fehler auftaucht, schreibe ich die entspr. zeile zusammen mit nem Errorcode in eine log-datei. So läuft alles schön durch und man kann hinterher schauen was nicht i.o. war.

Generell sollte man alle Daten von denen man nicht weiß "woher" sie kommen, bzw "von wem" überprüfen.

Um bei deinem beispiel mit dem Datum zu bleiben, könnte man ja auch anbeiten z.B. bei ungültigen Zeichen im Jahr dieses durch einen Standardwert ersetzen zu lassen. (z.B: 2008).

Gruß
tr909

[DeddyH]

Das Setzen eines Standardwertes ist ja schließlich auch eine Art der Fehlerbehandlung . Grundsätzlich finde ich, es ist immer besser, den User bereits im Entstehen auf Eingabefelder Eingabefehler hinzuweisen, als dass man es erst bei der Weiterverarbeitung bemerkt oder (noch schlimmer) nicht abgefangene Exceptions auftreten. Spätestens beim 10. Mal heißt es sonst nämlich "Sch... Programm", obwohl es sich eigentlich um ein Layer8-Problem handelt.

[tr909]

Zitat von DeddyH:

Das Setzen eines Standardwertes ist ja schließlich auch eine Art der Fehlerbehandlung .

ich meinte damit eher sowas wie.
Datum ungültig! Geben sie ein Gültiges Datum ein:
[abbrechen] [übernehmen] [für alle weiteren übernehmen]

Gruß
tr909

[alzaimar]

Sofern Du deine Anwendung nach Funktion und Darstellung klar trennst, ergeben sich diese Fragen gar nicht. Denn dann werden wohldefinierte Daten geladen und visuell dargestellt. Eingaben werden dann wieder in die zugrundeliegenden Datenformate transformiert, sodaß hier per Defintionem eine wie auch immer geartete Fehlerbehandlung auftritt. Und zwar immer und überall.

Sofern Du sauber programmierst, diese Trennung klar durchziehst und grundlegende robuste Konvertierungsroutinen (String To Date etc.) verwendest, die jeden Fehler sauber bemängeln, musst Du Dir keine Gedanken machen: Deine Anwendung wird automatisch 'bullet proof'. Und dabei ist es dann (fast) egal, ob es sich um eine Web- oder Desktopanwendung handelt.

Beispielsweise kann ein Endlicher Automat sehr zuverlässig und beweisbar sicher sämtliche syntaktischen Fragen beantworten, ohne das er je abstürzt. Wenn der Automat korrekt ist, läuft das Teil einfach niemals nicht nie nie nie! gegen eine Wand.

Ich würde mir eine mächtige Werkzeugkiste anschaffen (oder zusammenbasteln), die die Alltagsaufgaben zuverlässig und immer nach dem gleichen Schema löst. Ich geh mal davon aus, das Du sowas schon längst hast.