Dealing with runtime exceptions when reading from file

Question

Let's say I read a bunch of numbers from a text file. Each line is initially a string, I need to parse it to an integer. This is where the first exception might happen - NumberFormatException thrown by the Integer.ParseInt method. This is a runtime exception - unchecked exception that I don't have to catch or decorate my method with a throws clause.

What should I do if this exception happens, i.e. user has entered something that is not a number in the text file? Currently I'm just throwing a new checked exception (custom one) to indicate an incorrect format of the file.

And there's one more thing - after I've parsed the numbers, I create an object. The constructor of the object (takes two ints) however throws a runtime exception when the first parameter is larger than the second one. Again, should I catch this exception and throw my custom one?

Answer 1

There is no simple answer. Put yourself in the role of the user and think what they would expect, if there is a data file that is corrupted in the middle.

Let's say I have an address book with 1200 addresses, and there is one that your code cannot read. As a user, I expect to see 1199 addresses. Do I even expect an error message? I don't think so. Or at most once. Because if I use an application and every single time I search for an address I get a bloody error message I will be mightily pissed off.

Let's say my application just received a file with financial data. Say information about 217 bills that my company has to pay, and one that your code cannot read. As a user, I expect to be told that this file is corrupted, so that I can get back to the people sending the file and get a new one. Ignoring a bill that has been corrupted would be very, very bad and could lead to dire consequences.

So you see: It depends. Look at the situation and do whatever makes sense. Do it not in terms of a software developer, but from the point of view of the end user who needs the most useful results.

Answer 2

If you're expecting dirty data:

Dirty data is when some of the records may be dirty or not correct. The quality of data may not be high. In this case, just push the bad records into a skip file, log it and continue forward to the next one. At the end of processing, create a notification with a summary of results and note the skip file location.

This way one can process the majority of records and note the dirty ones for further remediation.

If you're expecting clean data:

Clean data means you expect every record to be valid. If the data is not clean, stop processing and create an alert. This scenario will require a pre-screen (first pass) of every record in the file to determine if it is valid or not. If the records are all valid, then the file is good and one can process. If the file is not valid, most likely the entire file is discarded and whoever/whatever is generating the file will have to create a new one to process.

Depending on your requirements, either option is acceptable.

Answer 3

Of course this depends on the implementation and the degree of complexity of your system. But generally speaking, I would opt for creating something like a FileParsingException and an ObjectBuildingException.

Then you would probably make an ObjectReader class that parses the file and creates the object (potentially delegated to a FileParser and and an ObjectBuilder class), catches these exceptions and creates the correct exception.

Then you can catch the exception at some point in the stack where you can give proper user feedback and maybe give the option of selecting another file or whatnot.

Good thing is that you can then add relevant information of what went wrong without enforcing complexity on the user of the class.

You for example might not want the client class to know that the file must contain ints because that would require it to implement logic that will break when your reader class changes. If there are a lot of clients, this becomes a hell very quickly. (this probably makes more sense when the parsing is more complicated).