Mon 28 Mar 2016 08:29:32 PM UTC, comment #4:
@Lachlan
Maybe it is better to forget about old textscan.m's behavior as regards ReturnOnError.
Explanation:
------------
The "old" textscan didn't fully implement ReturnOnError simply because it just couldn't, given the way it worked. So the parameter was accepted but didn't actually work at all in the sense that there as no way to stop textscan.m/strread.m from reading on, as long as the file columns were consistent until EOF.
Hence "not fully implemented" can be perceived as a sort of euphemism :-)
That is different from Matlab's textscan that always quits reading when it encounters a non-matching field, either with or without returning the results til the offending field, depending on ReturnOnError.
The new Octave textscan, like Matlab's textscan, works linearly trough files, so the "old" "intermediate" way isn't applicable anymore.
But if there's a use case for it I wouldn't mind if Octave's textscan could do better than Matlab's. In spite of what I wrote at the top of bug #47553 comment #5 :-)
The risk is of course that textscan encounters an error reading some field for a very good reason (viz. new file section / change of setup of the file, instead of a minor hickup/typo in just one field), and trying to continue reading may only yield error upon error until the end of (a possibly very very long) file.
Maybe "continue" should work as a sort of "job reprieved", i.e., ignore the erroneous field and insert EmptyValue, and allows just one more try, or a limited number of tries (say 5 or 10)? before giving up completely. But this gets very subjective....
|