On 7 May 2013 15:40, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > From my perspective, it should be fairly easy to make it clear... > > 1. File is opened, but not processed. Current line number = 1, total lines > processed = 0, records processed = 0.
I would say the current line number is also zero at this point; we have not started processing the first line. To my mind the current line stays current until the next line has begun. > 2. First line is processed. Current line number = 2, lines processed = 1, > records processed = 0. Again, I think current = 1 here, so long as reader has not read past EOL, we are still on the 1st line. > 3. Second line is processed, reached end of record. Current line number = 3, > lines processed = 2, records processed = 1. Likewise current = 2 here. It turns out to be fairly easy to fix this: if the reader is part-way through reading a line, just add 1 to the EOL count. > -Adrian > > > On 5/7/2013 12:08 PM, sebb wrote: >> >> On 7 May 2013 11:36, Adrian Crum <adrian.c...@sandglass-software.com> >> wrote: >>> >>> Maybe the method could be named better, something like >>> ExtendedBufferedReader.getCurrentLineNumber() - which would be different >>> than total lines processed. >>> >> Indeed, but at present there is no method which accurately reports the >> current line number for all situations. >> >> The method getLineNumber() currently reports the EOL count, which is >> the number of (complete) lines seen. >> The name is ambiguous. >> >> I don't think it is worth renaming until the design is sorted out. >> >>> -Adrian >>> >>> >>> On 5/7/2013 11:05 AM, sebb wrote: >>>> >>>> I've been looking at it further and there is an issue with 1-based >>>> counting. >>>> >>>> The line number currently counts the number of EOLs seen. >>>> This means it is currently accurate for total line count (which a >>>> 1-based system would not be) and is accurate for any completed >>>> records. >>>> >>>> It's only during processing of a line (before EOL is reached) that the >>>> count is off by one. >>>> I noticed that when I tested an invalid parse. >>>> >>>> One way round this would be to adjust the count when generating the >>>> IOException. e.g. if there are spurious characters before EOL it's >>>> obvious that one needs to add 1. >>>> >>>> I suspect it might be a bit tricky / more expensive to increment the >>>> line number only at the start of a line. >>>> >>>> Needs further work, which is why I started by just correcting the >>>> Javadoc to agree with the code. >>>> >>>> >>>> On 7 May 2013 08:00, Benedikt Ritter <brit...@apache.org> wrote: >>>>> >>>>> 2013/5/6 Gary Gregory <garydgreg...@gmail.com> >>>>> >>>>>> On Mon, May 6, 2013 at 5:49 PM, sebb <seb...@gmail.com> wrote: >>>>>> >>>>>>> The line number returned by >>>>>>> >>>>>>> ExtendedBufferedReader.getLineNumber() >>>>>>> >>>>>>> currently starts at zero, so an error in the first line in the file >>>>>>> is >>>>>>> reported as being in line 0. >>>>>>> >>>>>>> There does not seem to be any good reason for using a zero-based line >>>>>>> number, so I would like to change it to 1-based. Some tests will need >>>>>>> to be fixed. >>>>>>> >>>>>>> WDYT? >>>>>>> >>>>>> +1 >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>> Makes sense to me too. >>>>> >>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second Edition< >>>>>> http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>>> -- >>>>> http://people.apache.org/~britter/ >>>>> http://www.systemoutprintln.de/ >>>>> http://twitter.com/BenediktRitter >>>>> http://github.com/britter >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
