IMHO – The amount of error processing really depend on where what and when.

If the program is a simple batch job that runs at 2:00am, can be re-run if it fails and the output won’t be used till 9:00am in the morning, then maybe you can scrimp a bit on the error handling/reporting (But I bet after a few years of frantic 2:00am phone calls, you might change your mind.).

If it’s a heavily used data entry screen that’s expected to protect the integrity of a production system from invalid data , then I’d do a bunch more error checking, input validation, and reporting in human readable format (Like “Zip Code must be in the format of NNNNN-NNNN).

If the system handles 80% of the crude oil transactions in America in a real time highly visible environment, or monitors the pressure of a 747’s flaps as they extend down for landing, or perhaps handles the collision avoidance subsystem of a robotically controlled blood analyzer as strings of small glass veils containing potentially contagious sample whirl by…. I don’t think any amount of error handling/reporting is too much.

After 35 years of people wakening me up at 2:00am because a downstream job failed due to my program missing an opportunity to report bad (or just perhaps very unusual) data, you’ll find that I put as much error catching/reporting code as possible into every program I write, and lots more into the critical ones.