Feature/add raw line on error tuple option
Includes an option to add the raw csv line to the the error tuple and to the exceptions.
Coverage decreased (-4.02%) to 95.977% when pulling 3e6ae1d64e39cc1952477b5f19c45e81ad65cc62 on y86:feature/add-raw-line-on-error-tuple-option into 2cc26de998691720577c2ba792c6f2605a5b5d5a on beatrichartz:master.
Coverage decreased (-3.8%) to 96.154% when pulling e0750bb7cbcdb1d81cccd04d8454560ccb3738c8 on y86:feature/add-raw-line-on-error-tuple-option into 87c30b9b919652e5285c411eb7c0994bf4503074 on beatrichartz:master.
Thanks for putting this together I'll hopefully get a look later this week
Hey @y86 this is looking good, thanks! I think adding more information on errors is going to help users of this library get to the bottom of problems more quickly.
There are some issues with backwards compatibility in the pr as it is now. Also, there is some missing coverage of how errors get pulled through from the decoder to the top level module (CSV).
Is the idea that this should help with error messaging and human intervention, or do you use this to intervene programatically in case of errors? Depending on what the goal is, we could then ideate on possible backwards compatible ways of achieving the same thing.
Hey @beatrichartz , I am not too familiar with coveralls, so I wouldn't know where to start on the tests to bring it back from where it was. Regarding backward compatibility, as I mentioned on my reply to your comment, I think it is preserved.
Our use case for this was to easily return the problematic lines to the user in the interface so he could either fix them there and resubmit or download them into separate smaller file for review - the original csv files are quite large and sometimes they can't even edit them on Excel.
I think this functionality could still make it into a future release but would need updating. It's become a bit more challenging due to the parser accepting byte streams additionally to line by line input. Effectively we'll need to collect the full line, which the parser is already doing unless the byte size of the input is smaller than the line length, in which case it collects only the field.
Will have a look at adapting this hopefully soon.