CsvReader.HandleParseError should not throw an exception when the DefaultParseErrorAction is RaiseEvent

[lancasteradam]

Looking into dataplat/dbatools#6899 it seems that CsvReader.HandleParseError is not allowing the parsing to continue when the DefaultParseErrorAction is ParseErrorAction.RaiseEvent. Instead, an exception is thrown when the caller had intended to only raise events and continue processing the csv file.

The relevant code is at CsvReader line 1788.

A suggested change to line 1805 would be to have the following:

SkipToNextRecord();
break;

This would be similar to what is done in HandleExtraFieldsInCurrentRecord.

The switch statement from line 1806 to line 1824 should be removed.

The reason for removing that code is that the switch statement is resulting in a guaranteed exception being thrown from line 1809 since the default is being set to ThrowException on line 1803.

I would like to submit a PR for this, but I'm currently blocked by #74

[potatoqualitee]

It looks like someone forked the repo and fixed the blocker if you'd like to implement

#74 (comment)

To this end it is a straight drop-in replacement for the existing NuGet package LumenWorks.Framework.IO, but with additional capabilities; the other rationale for the project is that the code is not available elsewhere in a public source repository, making it difficult to extend/contribute to.

oh la la!

/cc @mike347

[mike347]

It looks like someone forked the repo and fixed the blocker if you'd like to implement

#74 (comment)

To this end it is a straight drop-in replacement for the existing NuGet package LumenWorks.Framework.IO, but with additional capabilities; the other rationale for the project is that the code is not available elsewhere in a public source repository, making it difficult to extend/contribute to.

oh la la!

/cc @mike347

Yep.. I actually looked at this but I was under the impression the dbatools package already includes this drop-in replacement. The DLL included shows version 4.0, which is the version the drop in replacement uses -- the original DLL stopped at version 3.8.0. Can you confirm if this is the case or not?

Looking at the repo for the drop in replacement, it seems like it still errors out because in my particular case, the problem is the first column is sometimes blank, which I believe is triggering the MissingFieldFlag, which in turn disallows AdvanceToNextLine. If my work laptop wasn't so locked down, I'd try compiling my own version of the DLL with this changed but it is what it is.