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

Reply via email to