[
https://issues.apache.org/jira/browse/CSV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763727#comment-17763727
]
Buddhi De Silva commented on CSV-270:
-------------------------------------
I have gone through the requirement discussed in this issue description and
have created a git diff on possible locations where we can introduce the new
Exception type for CSV parse issues.
I can work on this issue if we have possible go ahead for these changes.
[~ggregory] mentioned that we should consider using
'{_}IllegalStateException{_} ' whenever possible instead of introducing a new
exception type for CSV parse issue.
Therefore, I have looked at the official JavaDoc documentation for
{_}IllegalStateException{_}, it says:
_IllegalStateException_ -> "Signals that a method has been invoked at an
illegal or inappropriate time. In other words, the Java environment or Java
application is not in an appropriate state for the requested operation." [Ref:
https://docs.oracle.com/javase%2F7%2Fdocs%2Fapi%2F%2F/java/lang/IllegalStateException.html]
By simply looking at the definition of {_}IllegalStateException{_}, IMO, it
does not seems to be an ideal candidate to notify regarding the CSV parsing
issues. Therefore, I think it is best to introduce a new Exception such as
'{_}ParserException{_}' etc.
Link to the Git Diff containing comments:
[https://github.com/apache/commons-csv/compare/master...gbidsilva:commons-csv-osc:CSV-270]
Appreciate your feedback on this.
> Different Expeciton type on malformed csv files
> -----------------------------------------------
>
> Key: CSV-270
> URL: https://issues.apache.org/jira/browse/CSV-270
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
> Affects Versions: 1.8
> Reporter: Thomas Kamps
> Priority: Minor
> Attachments: malformed_format.csv
>
>
> In our application we support to read CSV files with a custom definable
> format. The problem is now, that a suer could give a CSV file, which doies
> not match the defined pattern, the CSVParser throws an IOException. This
> exception type could also be throws, if the reading of the itself fails.
> Wed like to have a simple distiction beween IO errors and file content errors.
> We could parse the IOException's message, but those messages could change and
> we have to know about all kinds of content errors in advance.
>
> So my suggestion is to throw a specialied exception, when malformed content
> is detected during parsing. So we could distinguish between thsoe two kind of
> errors very easily:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader(soneFile, encoding),
> csvFormat
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> //File cannot be read for some reason
> }
> catch (MalformedCSVException e) {
> //CSV content is malformed compared to given CSVFormat
> }
> {code}
> Currently we wold have to get the message from the IOExcpetion and check its
> pattern to get the problem.
>
> Here is a simple example how to get an IOException that occurs, when the
> files content does not match the given CSVFormat:
> {code:java}
> try (
> final CSVParser csvParser = new CSVParser(
> new FileReader("path/to/malformed_format.csv",
> StandardCharsets.UTF_8),
> CSVFormat.DEFAULT
> )
> ) {
> csvParser.getRecords();
> }
> catch (IOException e) {
> e.printStackTrace();
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)