-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tolerant mode #7
Comments
Sounds like every processor should have its own handling of errors (the default currently being panic). They should be modified by these flags but the question is whether we should also have flags that are specific to certain processors. I'd somewhat prefer if the number of optional command line arguments was kept as low as possible to make the CLI easier to use. Also maybe they should not be flags but rather enums like What is going to be the default? This The bad instances count should definitely go to the stderr final summary which is already there. |
If you find that
I agree -- each processor should have its own way of interpreting the flags but for simplicity, the flag should be global. If you need to handle errors differently in different parts of the processing pipeline, you can always just call
I like that solution a lot. |
Currently,
rjp
will stop when encountering any error, such as:serde
failing to parse an input line.Oftentimes, JSON lines files are noisy and contain lines with problems. It would be helpful to have some way to request "tolerant" behavior. For example,
rename_field
would not change an instance if the input fields are not found. Alternatively, problematic instances may be skipped in the output stream.It's currently not clear to me how the various processors should behave in this tolerant setting, or whether there should be more ways (for instance
--skip-bad-instances
,--stop-on-bad-instance
,--keep-bad-instances
?).The text was updated successfully, but these errors were encountered: