[boost] Re: Re: Re: [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-07 17:54:25

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:007d01c53b61$9a522b70$6601a8c0_at_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