If I understand correctly, the idea is that `parseLog` is a library function, while `parseLogSilently` and `parseLogInteractively` are examples of callers to that library.
If so, then the complexity of documentation and understanding of `parseLog` is pretty high. The caller needs to not only know the different conditions (e.g., `ParseError`), but also the available recovery strategies for those conditions (e.g., `SkipEntry`, `FixEntry`), and further that some of those strategies require an additional caller-provided function (e.g., `askToFixEntry`) with its own separate requirements (e.g., it takes an exception and returns a line).
Why would it not be better, since there are a finite number of provided recovery strategies, to simply hide that complexity within library-provided functions? E.g.:
(defn parse-log [file] ...) ; aborts on ParseError
(defn parse-log-skip [file] ...) ; skips bad lines
(defn parse-log-fix [file fix-fn] ...) ; emits (fix-fn line) for bad lines
Notice 'parseLogLoudly'. You could not implement that using your set of functions: you are not allowing for other code besides 'resume' inside the 'handle' blocks.
Also, I don't believe the mass duplication of code necessary for your approach is acceptable, even within a library.
>Notice 'parseLogLoudly'. You could not implement that
Fair point, and that's due to my failure in not providing an optional side-effect function arg to `parse-log-skip`. And this brings up a related point, namely that the author of the lib is still responsible for crafting the API. For example, if the author of `parseLog` had not included `recover FixEntry`, would it be possible for the caller to implement it via a condition system? Would that even be a good idea? Using the pseudo-python, the only approach I can think of would be:
Perhaps this is one of those cases where a simplified example helps convey the concept, but is too simple to show where other approaches would fall short.
>mass duplication of code
I'm not clear on what you mean. Multiple functions with different behaviour seems not to altogether different from one function with implicit switches that change its behaviour.
If so, then the complexity of documentation and understanding of `parseLog` is pretty high. The caller needs to not only know the different conditions (e.g., `ParseError`), but also the available recovery strategies for those conditions (e.g., `SkipEntry`, `FixEntry`), and further that some of those strategies require an additional caller-provided function (e.g., `askToFixEntry`) with its own separate requirements (e.g., it takes an exception and returns a line).
Why would it not be better, since there are a finite number of provided recovery strategies, to simply hide that complexity within library-provided functions? E.g.: