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.
