[Octave-bug-tracker] [bug #47538] textscan result different from 4.0.0 to dev

[Philip Nienhuis]

Follow-up Comment #4, bug #47538 (project octave):

@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....


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47538>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/