encoding/csv: add the true number of lines to ErrFieldCount

[btracey]

In Reader.Read(), if the true record length is not equal to the FieldsPerRecord field,
an ErrFieldCount error is returned. It would be nice if this error also included the
expected and found number of lines. So, for example, instead of the error string being
"wrong number of fields in line", it would be instead "wrong number of
fields in line. 15 read, 10 expected". The specific problem I encountered was that
my csv file had an extra delimiter at the end of the line, so one more record was read
than I expected. If the error message had also listed that there was one more record
than expected it would have been much easier to debug.

[robpike]

Comment 1:

Perhaps. I would like to resist using error strings as API, though. They exist to tell
you what's wrong, but you're asking them to tell you what's right. I think that's a bad
precedent.

Labels changed: added priority-someday, removed priority-triage.

Status changed to Thinking.

[btracey]

Comment 2:

Why is a bad precedent? I can see that we don't want to encourage blind changing of
numbers to pass error checks. However, in this particular case, I don't think this error
message change would tell you what is right, it would just be more specific about what
is wrong. I understand the criticism with the word "expected", but the intent of the
issue is to help the user understand what went wrong.

[btracey]

Comment 3:

As an addendum, I don't see the difference between this case (returning the number of
fields set and the number of fields read) and, for example, returning the filename that
couldn't be opened in os.Open. os.Open could just return "no such file or directory",
but the filename is added so it's easier to tell if a file is unexpectedly not there, or
if the filename passed to os.Open was incorrect.

[rsc]

Comment 4:

Labels changed: added go1.3maybe.

[rsc]

Comment 5:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 6:

Labels changed: added repo-main.

[nussjustin]

I think the easiest fix here is to add a new field "Field" to ParseError, which would contain the number of the field where the error occured (e.g. a,b"", c would report Field == 2), which for the ErrFieldCount case would contain the number of fields.

/cc @bradfitz