I am writing a program, and want to have the option for the program to
continue execution even should things go wrong. I use an option --ignore-errors.
The problem is what I do when an error occurs, set the values to zero, or fill them up with some values, for example taken from a simple unit test.
Need advice on this, and a useful approach. Without --ignore-errors, the program
will abort if a file is not found or there is an option missing.
It is almost always illogical to continue after not finding a data file. What are you planning to do? Make up defaults - like setting defaults in the absence of data.
A lot of applications will ignore the absence of/or an empty config file, but the application has reasonable defaults defined. This kind of thing- checking defaults - is done when the program starts.
If you are having issues with a long-running program aborting on file not found, consider using a system call like access() to enumerate all required file resources when the program starts. Instead of running for 5 minutes, then aborting.
You do not have to open a file to see if you can read or write to it.
You simply cannot process application data from a file if it is not there. Or permissions are wrong. Or because you don't want a 3:00am telephone call. The program has to abort. Period.
Other kinds of resources may go offline - like a tape drive - then be brought back online or mounted with the correct tape. You can, again, at the get-go enumerate resources, then tell the person running the report to mount the right tape.
For report programs, a huge percent of the lines of code often deal with checking parameters and resources, getting usernames and passwords, etc. The other 10% or so actually processes data. You have to do a ton of upfront work before trying to run the actual report code. This is true for lots of different kinds of apps.
The way your question is stated it is not clear.
And to add to JM's reply, what happens if your system aquires a corrupted file and or file
system?
Also suppose your code inadvertantly generates a divide by zero or encounters a major HW
error?
How are you going to ignore those effects?
Your system does not just have errors due to missing files or minor _script_design_ errors
but 'everything else and his brother included' too...
I would suggest you abort your idea and build-in error detection purely for your pwn peace
of mind...
Just my 5 pennoth...
It is good practice to distinguish between errors and warnings.
Errors are situations where - even if the program manages to continue - the results are unreliable if not unusable. You need to have a method of alerting the user or developer that something is wrong and needs to be fixed.
Warnings are situations that the user needs to be alerted to, but may not be detrimental to the quality of the output.
I think you will want to design your program around a definition of what constitutes an error and what a warning.