Skip to content

Conversation

@philipbel
Copy link
Contributor

Parser.enumerateAsArray() catches errors and throws CSVParseError.generic error indicated the row on which the block threw.

As far as I can tell, there should be no impact on existing code that passes a non-throwing function to enumerateAsDict().

  • Tests pass.

Copy link
Contributor

@DivineDominion DivineDominion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea makes perfect sense, thanks for the PR. And sorry for the delay, this went under my radar!

I left 2 change requests at the relevant code sections.

But I couldn't leave a PR comment on unchanges lines, so: could you also rephrase the - Throws: docstring to add that it may forward the rowCallback error, if any, to all functions that depend on this? (You essentially found and touched all relevant parts in your PR already I believe)

Thanks!

do {
try rowCallback(fields)
} catch {
throw CSVParseError.generic(message: "Error thrown by block for row \(rowIndex)")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, this doesn't change usage because the function is throwing anyway.

But could you avoid catching, wrapping, and rethrowing the error? User code throwing a MyVerySpecificError on failure in this callback will likely want to work with and maybe even catch MyVerySpecificError, not CSVParseError.generic, losing the original error's information completely here.

For context: I'm also not a fan of wrapping-and-rethrowing, because that adds another step to the debugging flow when you need to inspect the stack.

Just let rowCallback's error propagate will do The Right Thing in more cases 👍

Comment on lines +125 to +129
do {
try rowCallback(fields)
} catch {
throw CSVParseError.generic(message: "Error thrown by block for row \(rowIndex)")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above here, please:

Suggested change
do {
try rowCallback(fields)
} catch {
throw CSVParseError.generic(message: "Error thrown by block for row \(rowIndex)")
}
try rowCallback(fields)

thomasleese added a commit to thomasleese/SwiftCSV that referenced this pull request Dec 14, 2025
This updates the `enumerateAsArray` and `enumerateAsDict` methods to
accept a row callback function that throws an error. If the function
does throw an error it will be propogated to the caller of the
`enumerate` method.

This is inspired by swiftcsv#139 with
the review comments addressed to hopefully get this functionality in to
a release.

Co-Authored-By: "Philip B." <145237+philipbel@users.noreply.github.com>
thomasleese added a commit to thomasleese/SwiftCSV that referenced this pull request Dec 14, 2025
This updates the `enumerateAsArray` and `enumerateAsDict` methods to
accept a row callback function that throws an error. If the function
does throw an error it will be propogated to the caller of the
`enumerate` method.

This is inspired by swiftcsv#139 with
the review comments addressed to hopefully get this functionality in to
a release.

Co-Authored-By: "Philip B." <145237+philipbel@users.noreply.github.com>
DivineDominion pushed a commit that referenced this pull request Dec 16, 2025
This updates the `enumerateAsArray` and `enumerateAsDict` methods to
accept a row callback function that throws an error. If the function
does throw an error it will be propogated to the caller of the
`enumerate` method.

This is inspired by #139 with
the review comments addressed to hopefully get this functionality in to
a release.

## Allow other `ParsingState` closures to throw

This follows up on the previous commit which made the `finishRow`
closure of `ParsingState` allowed to throw an error, by updating the
other two closures of the private API to also throw an error.

Although this is not as neccessary for the private API, it keeps the
closures consistent, and there's no reason why one should throw and the
others should not.

---------

Co-authored-by: "Philip B." <145237+philipbel@users.noreply.github.com>
@DivineDominion
Copy link
Contributor

Superseded by #144 -- thanks for getting this started!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants