LB Booster
Programming >> Liberty BASIC language >> Input {from file} http://lbb.conforums.com/index.cgi?board=lblang&action=display&num=1449662136 Input {from file}
Post by joker on Dec 9th, 2015, 10:55am
Someone on the other forum had a problem with "Input Past End" for a file.
Since the INPUT command already knows it is operating on a file, why doesn't the INPUT command already know where the end of the file is?
Why are some BASIC commands so smart but so ignorant at the same time?
Re: Input {from file}
Post by Mystic on Dec 9th, 2015, 3:52pm
As far as I have seen most programming languages have an End of File (EOF) type check to see if the file you are reading data from has no more data.
There must be a reason why this is not left up to the language to just automatically assume that when you hit the EOF you're done.
It's not a BASIC only issue, but rather most programming languages follow this standard. As for "why" I have no clue. Re: Input {from file}
Post by Richard Russell on Dec 9th, 2015, 4:28pm
Since the INPUT command already knows it is operating on a file, why doesn't the INPUT command already know where the end of the file is?
It does. The 'input past end of file' error is intended to be helpful, not an annoyance! If you attempt to read more data than is in the file it is probably a fault in your program, so generating an error aids debugging. The alternative is to silently ignore the error and return 'non existent' data, but then the cause of the problem wouldn't be so apparent.
Richard. Re: Input {from file}
Post by joker on Dec 9th, 2015, 10:12pm
Quote:
The 'input past end of file' error is intended to be helpful, not an annoyance! If you attempt to read more data than is in the file it is probably a fault in your program, so generating an error aids debugging.
Well, I just thought that it would be more convenient for the INPUT command to only return the data up to the EOF along with the EOF error message.
I don't have my programming computer running, or I would find out if that actually is how it operates.
Re: Input {from file}
Post by Rod on Dec 10th, 2015, 11:25am
The input command works exactly as you describe. It returns the data and sets a flag telling you if you are at the end of the file. The eof() function reads that flag. So if you don't know where you are in the file or how many records there are you should check the eof() before trying to read the next record.
Re: Input {from file}
Post by joker on Dec 10th, 2015, 11:49am
Ok, thanks. That seems like the best way to handle it. (Obviously, because it has worked for so long that way! )
The "user error" is when one doesn't check for EOF error after each reading of the file.
Re: Input {from file}
Post by Richard Russell on Dec 10th, 2015, 1:02pm
Well, I just thought that it would be more convenient for the INPUT command to only return the data up to the EOF along with the EOF error message.
The phrase "EOF error" suggests there's some confusion between the EOF() function and the Input past end of file error. They are two separate things and my understanding is that in this thread we are discussing the error not the function.
When any error occurs, control is transferred to the error handler (either the default handler, or a user handler if an ON ERROR or TRY statement is active). Therefore there is no opportunity for the INPUT command to return anything "along with" the error, since it never returns!
There is a standard way to read all the remaining data in a file, without triggering an error (or using the EOF function):
)