On: An Introduction to Condition Handling for Non-Lispers

[lmm]

Sounds like this is just an opaque way of providing a strategy or callback to the parseLog method. Why not something along the lines of (scala):

  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)}
  }

[masklinn → lmm]

> Why not something along the lines of (scala):

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.

[lmm → masklinn]

Do you really want to handle error conditions in a resumey way far further up the stack? I'd expect most cases are either handle the error close to the cause, or a single application-wide handler (which could be provided with dependency injection).

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.

[masklinn → lmm]

> Do you really want to handle error conditions in a resumey way far further up the stack?

"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.

[brudgers → lmm]

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

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

[lmm → brudgers]

I'm not exactly a fan of that either