Ranges and Exception handling PR 2724

[Jonathan Marler via Digitalmars-d]

On Saturday, 15 November 2014 at 01:43:07 UTC, Robert burner 
Schadek wrote:
> This PR 
> https://github.com/D-Programming-Language/phobos/pull/2724 adds 
> an generic way of handling Exception in Range processing. 
> quickfur and Dicebot ask me to start a thread here so the 
> concept could be discussed.

I actually ran into this problem today when using the dirEntries 
function in std.file.  I was attempting to iterate all the files 
on my C drive and I got an Access Denied error which caused the 
DirIterator to throw an exception.  There's nothing I could do to 
catch the exception and continue.  I'm very glad people are aware 
of this problem and I'm glad you are trying to do something about 
it.

Correct me if I'm wrong, but it appears that the handleXXX 
methods allow the user to provide callback functions to "finish" 
the input range when an exception occurs.  "Finish" meaning it 
could restore the input range state or provide a whole new input 
range, whatever the user wants. Is this correct?  If so, I'm not 
sure how this could be used to solve the dirEntries case I ran 
into.  The logic to restore the DirIterator state after an 
exception could be quite complicated and error prone.

Maybe this is a naive solution but I thought I would share my 
idea to solve the dirEntries case in hopes it will help you solve 
the general case. The solution I thought of was to pass a 
callback function to dirEntries that would tell it how to handle 
errors.  An example of the callback could look like this:

// return true to throw an exception, false to skip the file and 
continue
alias FileErrorHandler = bool delegate(FileError error, 
const(char)[] filename) nothrow;

FileError could be an enum like:
enum FileError { accessDenied, ... }

So the dirEntries function could add an optional parameter

auto dirEntries(string path, SpanMode mode, bool followSymlink = 
true, FileErrorHandler errorHandler = null);

It looks "similar" to your solution with a key difference.  The 
InputRange is able to figure out how the error is suppose to be 
handled before it throws an exception and messes up any state it 
currently has (state including function stacks and the 
instruction pointer, etc).

I'm not sure how the API would look for the general case, but 
somehow the user will need to provide the input range with a 
callback.  Anyway, I don't know if this is helpful or not but 
good luck and I'll be waiting to see how this turns out.