From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-04-06 19:53:13
"Martin" <adrianm_at_[hidden]> wrote in message
>> 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
>> either hard errors, or conditions which are ambiguous as to the true
> 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
> is_x function to the filtering. In many cases you just want to iterate
> existing accesible files and/or directories, follow or ignore links. In
> cases a throw is an inconvenience since it complicates the code without
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
> 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
> capabilities to director_iterator (e.g. itr->is_directory() or itr =
> directory_iterator(path, files_only)). At least on Win32 this should be
> since the status is directly availble from the findfirst/findnext
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk