"Peter Dimov" <pdimov@mmltd.net> wrote in message news:007d01c53b61$9a522b70$6601a8c0@pdimov...
Beman Dawes wrote:
I don't buy that. I've seen really seriously flawed data get shipped to customers, doing untold harm to the business, because production scripts ignored errors.
"Ignore errors" is a broad brush that doesn't apply here.
bool is_directory( p ) throw();
// returns: true if p is a directory, false otherwise or on error
does not ignore errors.
If you try to come up with an example that does untold harm based on the above is_directory, it won't be easy. That's because every
void do_something_with( p );
will throw if p is mis-classified (and that's exactly as it should be).
You are assuming that after finding is_directory( p ) is false, the application then calls do_something_with( p ). But lots of applications don't work that way. If the condition isn't met, they go to some fall-back strategy which doesn't involve p at all. There is code like that in the current regression reporting system. I also ran into a real-world problem two years ago, where swallowing an error in a geographic application caused a fall-back which resulted in people (me included) driving to the wrong location in the wrong part of town . An expensive waste of time. Although it was a bit funny; I ended up talking to a homeless man living in a broken down automobile. It wasn't until he mentioned that a whole series of cars had driven up that morning and stared at him that I realized what had happened.
That aside, just to show that general principles don't always apply, here's an example where _not_ ignoring an I/O error does harm to the customer:
open file f read contents in buffer close file f // #1
open file g write buffer into g close file g
If #1 throws, you've just denied the customer access to the data in f, even though the data has just been read and may not be recoverable from this point onwards if the storage has failed physically at #1.
But the programmer always had the option of either not enabling exceptions for error reporting (assuming the I/O was done with the <fstream>) or catching exceptions and dealing with them. --Beman