Hallo,
der GPC gibt bei einem ReadLn nach dem Dateiende ja keine Fehlermeldung aus. Der FPC verhält sich ebenso. Gut so.
Wie ist das aber grundsätzlich? Kann man davon ausgehen, dass das bei jedem Compiler/Interpreter so ist, oder sollte man immer EOF vorher abfragen?
Andreas K. Foerster schrieb:
der GPC gibt bei einem ReadLn nach dem Dateiende ja keine Fehlermeldung aus.
Sollte er eigentlich schon, und meiner tut das auch. Kann sein, dass da mal ein Bug war, der inzwischen behoben ist ...
Der FPC verhält sich ebenso. Gut so.
Warum sollte das gut sein?
Wie ist das aber grundsätzlich? Kann man davon ausgehen, dass das bei jedem Compiler/Interpreter so ist, oder sollte man immer EOF vorher abfragen?
Nach obigen Antworten offensichtlich Letzteres. :-)
Frank
On Sat, Feb 08, 2003 at 11:23:24PM +0100, Frank Heckenbach wrote:
der GPC gibt bei einem ReadLn nach dem Dateiende ja keine Fehlermeldung aus.
Sollte er eigentlich schon, und meiner tut das auch. Kann sein, dass da mal ein Bug war, der inzwischen behoben ist ...
Könnte vielleicht auch ein Missverständnis vorliegen?
Ich meinte explizit Textdateien (ReadLn macht nur bei Textdateien Sinn). Bei anderen Dateien gibt es eine Fehlermeldung.
Ich habe nochmal meine alten TP Bücher vorgekramt. In TP ist das Verhalten auch genau so definiert.
Der FPC verhält sich ebenso. Gut so.
Warum sollte das gut sein?
Damit man nicht bei jeder Leseaktion eine Überprüfung durchführen muss, was den Code wesentlich verkomplizieren würde.
In meinem Quiz Programm habe ich einige ReadLn's drin, die theoretisch von einem EOF überrascht werden könnten. Bei Tests gab es jedoch nie Probleme (auch nicht mit {$I+}).
Andreas K. Foerster schrieb:
On Sat, Feb 08, 2003 at 11:23:24PM +0100, Frank Heckenbach wrote:
der GPC gibt bei einem ReadLn nach dem Dateiende ja keine Fehlermeldung aus.
Sollte er eigentlich schon, und meiner tut das auch. Kann sein, dass da mal ein Bug war, der inzwischen behoben ist ...
Könnte vielleicht auch ein Missverständnis vorliegen?
Ich meinte explizit Textdateien (ReadLn macht nur bei Textdateien Sinn).
Eben, deswegen meine ich auch Textdateien. ;-)
Ich habe nochmal meine alten TP Bücher vorgekramt. In TP ist das Verhalten auch genau so definiert.
Dass er nach dem Dateiende munter weiterliest?
Der FPC verhält sich ebenso. Gut so.
Warum sollte das gut sein?
Damit man nicht bei jeder Leseaktion eine Überprüfung durchführen muss, was den Code wesentlich verkomplizieren würde.
Oder eben `{$I-}' verwenden. Aber das musst du eh, denn beim Lesen können ja auch mal andere Fehler auftreten. Grundsätzlich besteht das Problem bei jeder I/O-Operation. Du hast zumindest drei Möglichkeiten:
- Jeden Befehl testen (sehr umständlich).
- Zusammengehörige Blöcke innerhalb von `{$I-}' klammern und am Ende testen.
- Eine globale Fehlerbehandlung schreiben. (Bei meinen CGI-Programmen mache ich das z.B. so, damit unerwartete I/O-Fehler (d.h. die, die ich nicht ausdrücklich mit `{$I-}' abfange), eine Meldung an den Client ausgeben und mir die Fehlermeldung per Mail zuschicken.)
Frank
On Sun, Feb 09, 2003 at 01:19:04PM +0100, Frank Heckenbach wrote:
Ich habe nochmal meine alten TP Bücher vorgekramt. In TP ist das Verhalten auch genau so definiert.
Dass er nach dem Dateiende munter weiterliest?
Dass er einen Nullstring bzw. den Wert 0 übergibt und ansonsten nichts geschieht.
Andreas K. Foerster schrieb:
On Sun, Feb 09, 2003 at 01:19:04PM +0100, Frank Heckenbach wrote:
Ich habe nochmal meine alten TP Bücher vorgekramt. In TP ist das Verhalten auch genau so definiert.
Dass er nach dem Dateiende munter weiterliest?
Dass er einen Nullstring bzw. den Wert 0 übergibt und ansonsten nichts geschieht.
Wie gesagt, ich weiß nicht, warum das sinnvoller sein sollte. Wenn man sich gegen Laufzeitfehler schützen will, muss man sowieso mit `{$I-}' arbeiten oder Fehler abfangen, und dann fällt Lesen nach EOF auch darunter. Und wenn nicht, erspart man sich, vor jeder Eingabe auf EOF zu testen, damit man nicht aus Versehen einen scheinbar gültigen Wert erhält und damit weiter arbeitet.
Frank