[boost] Re: [Filesystem] i18n

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-06 19:53:13

"Martin" <adrianm_at_[hidden]> wrote in message 
news:loom.20050405T083422-605_at_post.gmane.org...
>> 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 agree partly but there are 2 cases here.
>
> 1. The is_x are used as filter.
> Since there is no filtering directory_iterator available you need to use 
> the
> is_x function to the filtering. In many cases you just want to iterate 
> over
> existing accesible files and/or directories, follow or ignore links. In 
> these
> cases a throw is an inconvenience since it complicates the code without 
> any
> gain.

I agree to the extent that some of the cases when the current implementation 
throws can be eliminated. For example, is_directory() can safely be changed 
to return false rather than throwing in the case of a non-existant path. 
(And we would add a similar is_path()). But I just can't convince myself 
that silently swallowing an I/O error would be safe And given the plan to 
add a status() function which can provide error swallowing behavior, a 
programmer can get that behavior if really, really, required.

> 2. The is_x functions are used to verify user input/configuration or 
> program
> logic follows different paths depending on result of is_x functions.
> In this context I fully agree that io errors should throw an exception.
>
> One solution is to keep the current throwing is_x function and add 
> filtering
> capabilities to director_iterator (e.g. itr->is_directory() or itr =
> directory_iterator(path, files_only)). At least on Win32 this should be 
> easy
> since the status is directly availble from the findfirst/findnext 
> functions.

We really do need some form of directory iteration filtering. But I really 
want to finish the i18n changes (including those mentioned above) before 
working on that.

Thanks,

--Beman