I would welcome a non-throwing iterator as well. Most of our path iterating routines are littered with try catches to handle cases that aren't truly exceptional.
Is the litter just to deal with exceptions coming out of directory_iterator constructors? Or are there other use cases needing excessive try/catch blocks?
It is pretty much all about handling throwing constructors.
Also, what should the interface to a non-throwing directory_iterator look like?
First try - in addition to the current public members, add:
directory_iterator( const path & ph, std::nothrow_t ); // Effects (in addition to normal construction): If error occurs, save errno, and make iterator == the end iterator.
system_error_type error(); // Returns 0 if no constructor error, else errno saved by the constructor
This works well, however, pie in the sky, can we consider making the directory_iterator be no_throw by default ? Our catch implementations either logs the error and/or ignores it (pretty much all our current use cases), or pushes up a message to the user signaling the invalid input (only one occurrence of this behavior in our app): skip and move on is our most common scenario. Such a no-throw interface would at least not kill the iteration process in the advent of an error. The grief comes from a dev forgetting to try/catch the errors and the whole process being aborted prematurely and half completed. This usually gives unsatisfactory results for the user. We catch those problems in the QA cycle, but the fix isn't with a logic error, simply oversight from the developer. I would prefer having a reversed situation where the dev has the responsibility to look for errors if the specifications of the use-case requires to. The status quo is to simply try catch all path iterating routines. On a separate note, I ran into fun times with the MAX_PATH limitation on win32 =) The issue is that GetFileAttributesEx (used through fs::exists for one) fails to process anything bigger than MAX_PATH through the ascii interface. Exists would simply return false. This was causing an infinite loop in a routine that was attempting to create a unique filename through repeated tests. The wide version of GetFileAttributeEx supports a 32,767 character limit, on all but windowsME/98 platforms. Can this situation be improved by considering using the wide interface when MAX_PATH considerations kick in? Possibly introduce some asserts, or *gulp* exceptions? Cheers, -seb