From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-07 17:54:25
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk