Fehlermeldung oder keine Fehlermeldung, das ist hier die Frage

[Popov]

Angeregt durch einen anderen Thread eine Frage die mich schon immer beschäftigt hat - lieber eine Fehlermeldung oder keine Fehlermeldung?

Ein Beispiel:

Delphi-Quellcode:

Run('Tets');

Hier soll die Aktion "Test" durchgeführt werden, wird sie aber nicht, da es "Tets" nicht gibt. Falsche Bezeichnung. Abbruch mit Fehlermeldung oder sich still verhalten?

Nehmen wir an, dass das keine Funktion sein kann, somit ist auch kein Rückgabewert möglich.

Sicher, darauf gibt es nicht die eine richtige Antwort, und ich will nicht von den Fällen sprechen bei denen eine Fehlermeldung unbedingt sein muss, da man sonst von den falschen Voraussetzungen ausgeht. Und auf die Fehler will ich gar nicht hinaus, aber nehmen wir an - nur ein Beispiel - ein Zahlenfeld, jemand will 807 eingeben gibt aber 8o7 ein, was 87 ergibt. Fehlermeldung oder keine. Ist ein Falscher Wert, kann böse Folgen haben, andererseits kann man davon ausgehen, dass den Nutzer es schon merken wird.

Die Frage um die es geht ist, immer den Nutzer informieren oder soviel wie möglich abfangen?

Anderes Beispiel, eine StringList mit 7 Einträgen. Der Nutzer will etwas mit Insert eingeben, an die 8. Stelle, aber statt 8 9 eingibt. Die 8 wäre wie Add, einfach anfügen, 9 wäre Fehlermeldung, da außerhalb der Liste. Also lieber anfangen und an die 8. Stelle anfügen, gar nichts einfügen, oder eine Fehlermeldung?

Wir sind es gewohnt immer Meldungen zu kriegen. Html ist da ein sehr schönes Beispiel für ein anderes Konzept. Würde man auf jeden Fehler hinweisen, wären so mache Texte unlesbar. Also anderes Konzept - was falsch ist wird nicht beachtet. Nach Möglichkeiten evtl. das Beste draus machen, sonst Fehler aber abfangen.

[stahli]

Ich würde mal sagen: Je nachdem...

In einer Zeiterfassung interpretiere ich alle Zeichen <> Ziffern als ':'.
So kann man 12:30 Uhr auch mit dem Ziffernbock eingeben (12,30).

Bei der Zeitinterpretation würde das normalerweise einen Fehler ergeben.

Aber wieso soll "8o7" "87" bedeuten? Das ist eine reine Unterstellung! ;-)

Bei unbeabsichtigten Falscheingaben (ungültiger Validierung) würde ich überlicherweise einen Fehlerhinweis ausgeben.
In FireMonkey lässt sich sehr leicht ein roter Schein im das Control zuweisen.
Das ist z.B. ein Grund, warum ich mich derzeit gerade mal ein wenig damit auseinandersetze.

Tendenz: Auf Fehler (möglichst dezent) hinweisen.

[sx2008]

Ich würde empfehlen auf einen Fehler immer mit einer Exception zu reagieren.
Auf keinen Fall sollte man mit direkten Fehlermeldungen reagieren,
weil man dann unter anderem keinen Stacktrace erzeugen kann.

Delphi-Quellcode:

if telefonnr = '' then
begin
  // Falsch
  ShowMessage('keine Telefonnummer eingegeben');
  exit;
end;

if telefonnr = '' then
  // Richtig
  raise EPlausiCheck.Create('Telefonnummer fehlt');

Wenn eine Funktion nicht leisten kann was ihr Name verspricht, dann muss eine Exception ausgelöst werden.
Eine Funktion namens SaveStringToFile() sollte entweder den String in dem File speichern oder eine Exception auslösen.
Auf einen Returncode (False=Fehler, True=alles ok) zu vertrauen wäre schlecht, denn wie leicht kann es passieren, dass man eine Funktion aufruft ohne das Ergebnis zu prüfen.

Siehe auch: http://de.wikipedia.org/wiki/Fail-Fast

Zitat:

Some people recommend making
your software robust by working
around problems automatically.
This results in the software “failing slowly.”
The program continues working right after an
error but fails in strange ways later on.
A system that fails fast does exactly the opposite:
when a problem occurs, it fails immediately
and visibly. Failing fast is a nonintuitive
technique: “failing immediately and visibly”
sounds like it would make your software more
fragile, but it actually makes it more robust.
Bugs are easier to find and fix, so fewer go into
production.

[Popov]

Nun ja, SaveStringToFile ist vielleicht einer der Fälle wo eine Fehlermeldung angebracht ist. Denn wenn ein wichtiger Text nicht abgespeichert werden kann, dann sollte man es schon wissen.

Aber die klare Aussage, auf Fehler immer mit Fehlermeldungen reagieren zu müssen, ist die Anpassung des menschlichen Denkens an die Binärdenkweise der Computer. Gehe ich in den Supermarkt um 3-lagiges Toilettenpapier zu kaufen, weil zu Hause auf der letzte Rolle nur noch paar Windungen vorhanden sind, und stelle fest, dass 3-lagiges Toilettenpapier gerade alle ist, kann ich im Kopf mit raise eine Exception auslösen und ohne Toilettenpapier nach Hause gehen. Am nächsten Tag habe ich evtl. ein mächtiges Problem. Oder ich prüfe eine Alternative. Wie wäre es dieses Mal mit 4-lagiges Toilettenpapier?

Alternativen. Ich hab mal ein mittelgroßes Programm geschrieben, das nur aus Funktionen bestand. Das Konzept - alles wird über Parameter übergeben und jede Funktion, ohne Ausnahme, gibt einen Fehlercode zurück der mitteilt, ob die Funktion erfolgreich war. Die Möglichkeiten dieses Konzepts waren nicht ohne, auch wenn der Aufwand viel größer war, denn im ganzen Programm gab es keine Fehlermeldung. Auf jedes Problem gab es immer eine Alternative. Aber es geht mir nicht um das Konzept, denn zuletzt brummte mir der Kopf. Auf alles eine Alternative anzubieten bedeutete Aufwand. Ich hab es nur gemacht um es mal auszuprobieren ein Programm ohne Fehlermeldungen zu programmieren und alles abfangen zu können. Eine Fehlermeldung ist da die perfekte Antwort, die da sagt - das Problem sitzt vor dem Monitor. Das ist dein Problem, löse es selbst.

Aber zurück zu der Eingangsfrage. Immer Error oder Alternative. Errors lösen Probleme des Programmierers, denn er übergibt das Problem an den User. In einer Bitmap soll ein roter Kreis gezeichnet werden, rot ist aber gerade alle, dann Fehlermeldung ober eher blau nehmen? In eine StringList soll an -1 ein String eingefügt werden, Fehlermeldung, oder abfangen und in 0 eingeben?

[DeddyH]

Zitat:

Zitat von Popov (Beitrag 1193853)

Aber die klare Aussage, auf Fehler immer mit Fehlermeldungen reagieren zu müssen

Wo stand das denn?

Zitat:

Zitat von Popov (Beitrag 1193853)

kann ich im Kopf mit raise eine Exception auslösen und ohne Toilettenpapier nach Hause gehen. Am nächsten Tag habe ich evtl. ein mächtiges Problem.

Ganz klar falsches Exception-Handling.

Zitat:

Zitat von Popov (Beitrag 1193853)

Auf jedes Problem gab es immer eine Alternative.

Das möchte ich doch stark bezweifeln. Irgendwann kommt immer ein Problem hoch, an das man nicht gedacht hat und deshalb keine Alternative anbieten kann.

Zitat:

Zitat von Popov (Beitrag 1193853)

Errors lösen Probleme des Programmierers, denn er übergibt das Problem an den User.

Oder an den Aufrufenden. Wer der auch nicht weiter weiß, dann kann er die nächsthöhere Schicht fragen. Erst ganz oben ist das dann eben der User.

[Popov]

Zitat:

Zitat von DeddyH (Beitrag 1193860)

Wo stand das denn?

Nirgendwo. Ich hab Exceptions gemeint und Fehlermeldungen geschrieben. Der Rest stimmt soweit. Sicher, Exceptions kann man abfangen, aber das ist nicht die Frage des Threads.

[DeddyH]

Es kommt doch darauf an, ob das Programm seine Arbeit auch nach Auftreten eines Fehlers noch zuverlässig weiter verrichten kann oder nicht. Es muss ja auch nicht immer direkt eine Fehlermeldung sein, die man dem Benutzer präsentiert, man kann ihn ja je nach Situation auch entscheiden lassen, wie weiter verfahren werden soll. Ist das fehlerverursachende Modul eher unwichtig (also mehr in die Richtung "nice to have"), kann man es auch mit einer stillen Exception einfach ignorieren. In allen anderen Fällen sollte man IMHO aber dann doch den Benutzer informieren, dass etwas Wichtiges fehlgeschlagen ist.

[p80286]

Meiner Meinung nach gibt es zwei(drei) Möglichkeiten für Fehler,
a) der Benutzer hat nicht wie erwartet agiert, falsche Eingabe
b) die Umgebung reagiert nicht wie erwartet, Netzverbindung gestört
c) der unwahrscheinliche Fall, daß der Programmierer einen Fehler gemacht hat.

Der dritte Fall sollte abgefangen werden. Wenn a und b unter den Tisch gekehrt werden, dann gibt es Ergebnisse, mit denen der Benutzer meist nicht rechnet.

Gruß
K-H

[Popov]

Ich glaube die Frage hat sich verselbständigt und ist in eine etwas falsche Richtung gegangen. Irgendwann hab anscheinend auch ich dann den Faden verloren. Ok, zurück zu der eigentlichen Frage.

Es geht hier weniger um die Frage ob Fehlermeldungen sinnvoll sind oder nicht. Die Frage ging eher in die Richtung wie viel Fehlermeldungen man abfangen kann? Ist es ethisch zu vertreten eine falsche Eingabe zu korrigieren?

Findet die Polizei ein unerschlossenes Fahrzeug, reagiert sie mit einer Fehlermeldung. Das Fahrzeug wird abgeschleppt, dem Halter entstehen hohe Kosten. Alles ist Rechtens. Alternative wäre die Tür zu öffnen, den Türknopf runter zu drücken, Tür wieder schließen. Problem behoben. Das ist aber gegen das Gesetz.

Zurück zu Programmierung. Mein Beispiel noch ein mal. Insert -1 gibt es nicht, aber 0 gibt es. Fehler korrigieren oder doch eine Fehlermeldung? Im ersten Fall kriegt der Nutzer von seinem Fehler nichts mit, wird aber auch nicht im Fluß der Arbeit gestört. Im zweiten Fall wird er unterbrochen, hat aber die Möglichkeit seinen Fehler zu korrigieren.

Natürlich kann man sagen, von Fall zu Fall, aber man kann das nicht immer so handhaben. Wie oft hat man eine Eingabe und kann die falsche Eingabe anfangen. Google macht das nett. Gibt man das Wort falsch ein, liefert Google oft schon vorab das Ergebnis mit korrigiertem Wort. Sowas meine ich.

[Bummi]

Dann mach es (gegf. in mehreren Stufen) einstellbar.
Mich z.B. nervt es wenn ein Programm meint intelligent sein zu müssen und mir meine Eingaben verbiegt.

[stahli]

:thumb:

[Popov]

Zitat:

Zitat von Bummi (Beitrag 1193979)

Dann mach es ...

Ich mache nichts. Es geht nicht um ein aktuelles Problem. Mich interessiert es nur wie andere es sehen. Du bist also für eindeutige Exceptions. Ok.

[Bummi]

Zitat:

Du bist also für eindeutige Exceptions

Ich bin für einstellbar ...

[stahli]

Beispiel (hoffentlich fiktives) für ein Navi:
Der User gibt "Münschen" ein (ist z.B. ein Dorf in der Nähe oder ein Schreibfehler statt "Münsen").
Das intelligente Navi korrigiert den Eingebefehler in "München" ... Gute Fahrt!

Manche Programme (Word, iPhone...) gehen gelegentlich in die Richtung.

[Furtbichler]

Zitat:

Zitat von Popov (Beitrag 1193985)

Zitat:

Zitat von Bummi (Beitrag 1193979)

Dann mach es ...

Ich mache nichts.

Oh je. Bummis Beitrag ist ein Vorschlag und liest sich wie 'Wie wäre es, sich Folgendes zu überlegen:...'.

Ich finde es grauenvoll, wenn eine Anwendungen meine Eingaben interpretiert. Wenn die Polizei ein unverschlossenes Fahrzeug findet und so lieb ist, es abzuschließen, handelt sie sich derben Ärger ein, denn es wäre denkbar, das ich den Schlüssel mit Absicht im Auto (und nur dort) habe (weil ich einfach so dämlich bin). Mit der 'Autokorrektur', die ja lieb gemeint ist, wird nun genau das Gegenteil erreicht: Die Situation wird nicht glattgebügelt, sondern verschlimmert.

Autokorrektur geht fast immer nach hinten los, eben weil sie automatisch ist. In 1000 Fällen ist es ok und in einem nicht. Aber den einen Fall kriegst Du ja mit der Autokorrektur nicht mit. Blöd, wenn deswegen ein Flugzeug abstürzt oder der Reaktor heißläuft.

Das Bestreben, eine Anwendung fehlertoleranter zu gestalten, wäre, mit Standardvorgaben zu arbeiten. Dann würde etwa beim Fehlen eines Dateinamens in eine Datei 'OhneNamen.Txt' gespeichert werden. Dann kann man dem Anwender noch sagen, das die Daten sicher abgelegt sind und er sich doch irgendwann vielleicht er, wenn er will und lustig ist (und nicht Popov heißt, denn der macht ja nichts :mrgreen) wo war ich achja die Datei kopieren und umbenennen kann.

Letztendlich ist der Versuch, klüger als der Anwender zu sein, nicht leicht umzusetzen, denn selbst der dümmste aller DAU ist 1000x schlauer als die pfiffigste Autokorrektur.

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1193988)

Das intelligente Navi korrigiert den Eingebefehler in "München" ... Gute Fahrt!

Und dann wollte jemand wirklich nach Münsen,
oder er wollte nach Dresden und das "intelligente" Navi leitet ihn ins schöne Sachsen.

:roll: