|
If you were logged in you would be able to see more operations.
|
|
|
|
Provide better error reporting when errors occur while parsing an input file.
For example, if a field containing incorrect data could not be parsed, then provide more detailed error information than simply throwing a basic runtime exception (E.g. parsing a date field throws a IllegalArgumentException in org.springframework.batch.io.file.FieldSet).
A common requirement in my projects is often the ability to provide detailed feedback to the users (typically System admin) in case something goes wrong while reading input files. Often it is also desirable to try to read the whole file and provide a collection of occurred errors.
Is there maybe a way to hook into the validator? Also, it would be great if reported errors could contain the row number and field number.
|
|
Description
|
Provide better error reporting when errors occur while parsing an input file.
For example, if a field containing incorrect data could not be parsed, then provide more detailed error information than simply throwing a basic runtime exception (E.g. parsing a date field throws a IllegalArgumentException in org.springframework.batch.io.file.FieldSet).
A common requirement in my projects is often the ability to provide detailed feedback to the users (typically System admin) in case something goes wrong while reading input files. Often it is also desirable to try to read the whole file and provide a collection of occurred errors.
Is there maybe a way to hook into the validator? Also, it would be great if reported errors could contain the row number and field number. |
Show » |
|
Improvement
Closed
Major
Improve error reporting when parsing input files
What's wrong with IllegalArgumentException (as long as the error message tells you what happened)? Also a date parsing problem actually gives you quite detailed information about the error (as per the unit tests).
If you want to read the whole file before any processing you can already arrange that as a first step in the job, followed by another step to do some processing. Nothing wrong with that, except if the file is large you might be forced to read it twice (which I can't see any way around even with enhancements).
There is a hook for validation in FlatFileItemProvider, but it is intended to be used for validating objects after they are mapped from a FieldSet, so that's not quite what you wanted?