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