[boost] Re: [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-03 20:59:40

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:01cf01c536d0$ea2cf700$6601a8c0_at_pdimov...
> Rob Stewart wrote:
>> From: Beman Dawes <bdawes_at_[hidden]>
>>> Presumably then exists() and the is_x() functions would be specified
>>> in terms of status() and lstatus() results. So in effect exists()
>>> and the is_x() functions are conveniences, very useful in many but
>>> not all cases, and safe to use casually since obscure errors will
>>> cause exceptions.
>>
>> Sounds great to me!
>
> I find it very odd for exists/is_* predicates to throw exceptions... and 
> even odder for this to be described as "safe to use casually" when casual 
> use may lead to aborting an operation when this is not desirable and the 
> exception does not imply failure.

To me, an io error does imply some kind of failure, and a serious one at 
that. Remember that errors reported by the system API call (stat() or 
similar) have been analyzed, and those that clearly indicate existance or 
not are not treated as errors. What is left are error codes that represent 
either hard errors, or conditions which are ambiguous as to the true status.

I've been burned badly in the past by trying to continue after an io error, 
so really prefer errors to be announced nosily and as soon as possible. I'm 
also inclined to think that reporting a directory as !is_directory() when 
there is a permissions clash, even though it appears on a "ls" or file 
system browser as a directory, is likely to raise eyebrows and generate 
endless mistaken bug reports.

But it looks from other's responses that I'm out voted. And it isn't just 
people who have commented on this list. I tested the Python os.path library, 
and its isdir() function doesn't even throw if the entire file system goes 
offline.

--Beman