Also, I don't believe the mass duplication of code necessary for your approach is acceptable, even within a library.

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:

    def parseLogInteractively(file):
      do:
        return parseLog(file)
      handle ParseError, e:
        line = askToFixEntry(e.text)
        retry

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 parseLog just returned an error upon failure we would have to same problem as exceptions do, as explained in section 1. So we have to make parseLog return two lists: one of entries, and one of errors. We would then have to search through the error list fixing and reparsing each error. In Python this would be something like,

  def parseLogInteractively(file):
      return parseLinesInteractively(file.readLines())

  def parseLinesInteractively(lines):
      entries, errors = parseLines(lines)
      if errors:
          entries += parseLinesInteractively(askToFixEntry(e.text) for e in errors)
      return entries

e.g.

    def parseEntry(line):
        try:
            parsed = foo(line)
            yield parsed
        except SomethingBad:
            yield None

It would be extremely awkward, you'd need a big dispatch table handling the generator's result and send()ing restarts up to the generator, and of course you lose condition's ability to work through stacks of blissfully unaware code, and to have default behaviors (in Smalltalk, the default behavior — in an interactive image — is to pop up a dialog asking the user if he wants to unwind the stack [as in an exception], to open a debugger at condition point or to try resuming the condition [under the assumption that the user fixed some incorrect method, or checked his network access])

And, yes, I'm not saying that manually implementing pseudo-restarts is something I'd ever want to do, but some vague skeleton of the possibility is there.

    ...
    except SomethingBad:
        yield None 
        restartRequest = yield None
        if restartRequest:
            do whatever is necessary to go on

although perhaps passing a 'handlers' object down, with which handler functions could be registered might be better?

  def parseLogInteractively(file):
    entries = list()
    for line in file:
      entry = parseEntry(line)
      if entry.failed:
        entry = askToFixEntry(entry)
      entries.append(entry)
    return entries

(By the way, you're looking for Haskell's Either type, but ([a],[b]) and [Either a b] are equivalent here.)

  def parseLog(file):
    list = []
    for line in file:
      list.append(parseEntry(line))
    return list

  def parseLog(file):
    for line in file:
      yield parseEntry(line)

  def parseLogLoudly(file):
    for entry in parseLog(file):
      if entry.failed:
        print "Warning:", entry.message
      else
        yield entry

  def parseLogSilently(file):
    for entry in parseLog(file):
      if not entry.failed:
        yield entry

  def parseLogInteractively(file):
    for entry in parseLog(file):
      if entry.failed:
        yield askToFixEntry(entry)
      else
        yield entry

The reason it doesn't have those names is because it is more general; you can also use Either to model things like early termination. The generic names just make it clearer that it isn't exclusively for error handling unlike exceptions. In other languages using exceptions for more generic control flow is considered poor style, but in Haskell using Either for non-error cases is completely reasonable.

  def parseLogInteractively(file) = parseLines(file.readLines(), error => askToFixEntry(e.txt))

  def parseLines(lines, errorHandler) = lines flatMap {
    tryParseLine(_) fold {success(l) => Some(l)} {error => errorHandler(error)}
  }

Because that only works for very flat stacks, otherwise your callback will start infecting more and more method less and less related to what's actually causing the error, and then you'll have to move to a mapping of callbacks as different parts of the stack will want their own error callback.

The condition handling approach just seems too magic to me. It seems to mean the "inner" code calls another method defined somewhere else - but that "somewhere else" is defined by the call stack, something that's not really very visible in the code.

"Way far" is relative and depends on a number of factor. And I don't consider half a dozen stack frames "way far", it's very easy to attain when using a coding style emphasizing small short methods which call one another.

You also have no bloody idea how the library works internally.

> I'd expect most cases are either handle the error close to the cause

Again, "close" and "far" is relative. I want to handle the error at the closest point to its triggering, but I'm also limited by the data available to know how to handle it. One pushes the handler down the stack, the other up.

> The condition handling approach just seems too magic to me.

There's nothing magic to it.

> It seems to mean the "inner" code calls another method defined somewhere else - but that "somewhere else" is defined by the call stack

Welcome to dynamic scoping, there are cases where it's useful.

> something that's not really very visible in the code.

How is "I'm signaling a condition" not very visible in the code? It says right there that it signals a condition.

They're nothing compared to Lisp's macro facility.

He also mentions 'one person having responsibility'. Does he mean a benevolent dictator? Linux and Python have that. They're imperfect in their own ways too.

[1]: http://news.ycombinator.com/item?id=4369699

[2]: http://lubutu.com/soso/usul

(Please, can this stop?)

(Netcraft confirms: BSD is dying!)