"Martin" <adrianm@touchdown.se> wrote in message news:loom.20050405T083422-605@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