[boost] Re: [Filesystem] i18n

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-04 06:04:51

"Beman Dawes" <bdawes_at_[hidden]> writes:

> "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. 

I wouldn't say that.  My opinions were pretty underinformed as I tried
to make clear.  Your arguments above sound pretty convincing to me.

> 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.

Rather than accept it at face value, I would check with the
maintainers and/or comp.lang.python to see whether that's intentional
or incidental behavior.  I'm sure you'll find that the behavior in
that case isn't well-specified.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com