Seite 5 von 6
Verfasst: 27.05.2007 15:18
von AND51
Das mit der Meldung im Debugger ist ja eine gute Idee, aber stell dir doch mal eine Situation vor, in der man vielleicht nicht selbst bestimmen kann, was ReplaceString$ und SearchString$ sein sollen.
Im Endeffekt könnte dein Programm in eine solche Situation geraten:
Code: Alles auswählen
replace.s=InputRequester("", "", "")
search.s=InputRequester("", "", "")
result.s=ReplaceString(Data$, search, replace)
Was nützt dir da ein Debugger-Check, wenn du dein Programm mit diesem Code aber fertig-kompilierst und weitergeben musst? Und ich persönlich habe keine Lust alles und jeden vorher mit
If zu prüfen. Ich meine: Ich prüfe schon wichtige Dinge, wie Dateien oder Load*(), aber nicht solche Sachen wie OpenWindow. Und replaceString ist ja noch unwichtiger als OpenWindow...
Verfasst: 27.05.2007 15:25
von Kaeru Gaman
> Und ich persönlich habe keine Lust alles und jeden vorher mit If zu prüfen.
dann solltest du nicht für andere menschen programmieren.
> Im Endeffekt könnte dein Programm in eine solche Situation geraten:
dann ist es schlecht programmiert!
wie ich bereits weiter oben schrieb:
> auch hier würde ich vorher testen, ob der suchstring leer ist, um den benutzer darauf hinzuweisen.
> aber egal in welcher programmiersprache solltest du deinem benutzer eine
> meldung geben "der Suchstring sollte nicht leer sein", wenn er es versucht.
ts-soft hat es so gesagt:
> Benutzereingaben sind grundsätzlich zu prüfen, bevor man sie weiterverarbeitet.
> Entweder man verhindert Falscheingaben oder man prüft sie.
wo bleiben denn da noch fragen offen oder wo gibt es was um den pudding zu diskutieren?
1. JA, es ist ein Bug, der befehl darf nicht freezen.
2. wenn du eine Benutzereingabe ungeprüft verarbeitest, dann ist da auch ein BUG vor der Tastatur.
Verfasst: 27.05.2007 18:06
von String
Zitat
Benutzereingaben sind grundsätzlich zu prüfen
Zitat Ende
Das ist 100% richtig
Aber!
Wieso sollte man auf die Idee kommen, eine Variable zu Prüfen.
Die in einem Befehl ausgeführt werden soll, von dem man ausgehen kann
das er bei einer null Eingabe auch null zurück liefert
sofern der Befehl keinen Bug enthält.
Das ist doch totaler Quatsch.
Mann kann es mit dem Prüfen auch übertreiben.
Verfasst: 27.05.2007 18:39
von ts-soft
>> das er bei einer null Eingabe auch null zurück liefert
Das wäre evtl. sinnvoll, ist aber kein Bug, da der Compiler exact das ausführt
was im Code steht. Das dies unendlich dauert ist ja ein ganz anderer Schuh.
Mir ist ein Compiler, der das ausführt was ich im sage lieber, als einer der
mir fälschlicher Weise 0 zurückgibt. Weil das ist auch falsch.
Compilerwarnung wäre in jedemfall angebracht. Ansonsten liegt es eben in
der Verantwortung des Programmierers. Ist ja eine Compilersprache und
kein Basic-Scripting for Kids. Prüfen kann man nicht übertreiben, das ist
das wichtigste beim programmieren überhaupt, wer dazu zu faul ist, sollte
sich lieber ein anderes Hobby suchen, weil programmieren kann man mit so
einer Einstellung nicht lernen.
Verfasst: 27.05.2007 18:56
von String
ts-soft hat geschrieben:(Zitat) >> das er bei einer null Eingabe auch null zurück liefert (Zitat Ende).
Das wäre evtl. sinnvoll, ist aber kein Bug,
Das ist ja auch kein Bug.
Sondern das sich der Compiler aufhängt ist ein Bug.
Verfasst: 27.05.2007 19:12
von ts-soft
>> Sondern das sich der Compiler aufhängt ist ein Bug
Suche nach nix dauert unendlich. Physikalisch und logisch korrektes Verhalten
Verfasst: 27.05.2007 19:24
von String
Wenn ich nach nichts suche,
dann benötige ich erstens dafür keine Zeit und kann mich auch nicht verlaufen.
Verfasst: 27.05.2007 19:36
von Kiffi
ts-soft hat geschrieben:>> Sondern das sich der Compiler aufhängt ist ein Bug
Suche nach nix dauert unendlich. Physikalisch und logisch korrektes Verhalten
OK, dann drehen wir es halt um. Ich bin dafür, dass der Compiler sich bei
folgendem Befehl auch aufhängt.
Grüße ... Kiffi
Verfasst: 27.05.2007 19:45
von ts-soft
Kiffi hat geschrieben:ts-soft hat geschrieben:>> Sondern das sich der Compiler aufhängt ist ein Bug
Suche nach nix dauert unendlich. Physikalisch und logisch korrektes Verhalten
OK, dann drehen wir es halt um. Ich bin dafür, dass der Compiler sich bei
folgendem Befehl auch aufhängt.
Grüße ... Kiffi
Ich auch!
Folgefehler suchen ist nämlich schwieriger als Fehler zu suchen
Wenn der Debugger das meldet und der Code sich dort aufhängt, brauche ich
nämlich nicht mehr suchen. Erspart viel Arbeit
("MU")
Verfasst: 27.05.2007 19:58
von String
Egal wie und ob das Problem behandelt werden sollte.
Muss man da jetzt einen bugreport im internationalen Forum melden.
Oder haben das die richtigen Leute schon mitbekommen?