6 ms·

An Introduction to Condition Handling for Non-Lispers

104 points by lubutu 14y ago

qznc 14y ago
What I do not like about this: You expose implementation details to the outside with those recover points. In the same sense exceptions in Java expose implementation details, though. For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it. Basically, I want a more convincing example for condition handling.
- lubutu 14y ago
  Suppose we were attempting to write parseLogInteractively by just returning errors (as in idiomatic Go). 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 Again we lose the ability to abstract the function 'parseLog'. And I don't know about you, but this looks far worse to me than "resume FixEntry" in terms of exposing implementation details.
  - oddthink 14y ago
    In python, I usually deal with this with generators. It's not as elegant as conditions, but it works well enough. I've never tried to permit custom restart-like behavior, but now that generators are coroutines, it should be doable. e.g. def parseEntry(line): try: parsed = foo(line) yield parsed except SomethingBad: yield None Common lisp could really use some better coroutine support (and some way to specify generic sequences). Sure, you can do it with macros, but it gets horrible fast. Have you looked at SERIES, for example?
    - masklinn 14y ago
      > I've never tried to permit custom restart-like behavior, but now that generators are coroutines, it should be doable. 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])
      - oddthink 14y ago
        Thanks for the pointer; I've been learning some Smalltalk lately, but I haven't yet looked into the condition system. 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.
    - praptak 14y ago
      If you want the restart, you need to take advantage of the PEP-342 two-way yield(), as in: ... except SomethingBad: yield None restartRequest = yield None if restartRequest: do whatever is necessary to go on The problem with the above is that the double yield() ugly. You cannot do this with single yield() because the caller would have to know in advance that next() will return None.
    - whism 14y ago
      Generic sequences are coming to common lisp. I'm working on a simple implementation inspired by clojure which I'll be posting to /r/lisp in the coming week.
    - Chris2048 14y ago
      Maybe something like: https://gist.github.com/3598432 https://gist.github.com/3598432 although perhaps passing a 'handlers' object down, with which handler functions could be registered might be better?
  - qznc 14y ago
    Do not separate errors and entries. Instead use something like Haskell's Maybe, but instead of an empty Nothing-object you return something which contains error information: def parseLogInteractively(file): entries = list() for line in file: entry = parseEntry(line) if entry.failed: entry = askToFixEntry(entry) entries.append(entry) return entries A design question arises: Do you need to fix parse errors before you can proceed with next entry? If not, the error handling can be done by whomever calls parseLog.
    - lubutu 14y ago
      The abstraction problem remains: you are reimplementing parseLog every time you write a new handler, as I described in section 1. (By the way, you're looking for Haskell's Either type, but ([a],[b]) and [Either a b] are equivalent here.)
      - qznc 14y ago
        No, you only implement this one: def parseLog(file): list = [] for line in file: list.append(parseEntry(line)) return list Or better (more pythonic imho): def parseLog(file): for line in file: yield parseEntry(line) The second version is lazy (if file reading is lazy), so you can even abort parsing or fix the state on an error. Here are your different versions all reusing parseLog from above and equivalent line count to condition handling: 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 (Haskell's Either has "Left a" or "Right b". I want something like "Just value" or "Error msg", but you are right Either is nearer than Maybe)
        mooism2 14y ago
        (It's conventional to use Left for errors and Right for successes.)
  - lmm 14y ago
    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 14y ago
      > 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 14y ago
        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 14y ago
        > 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.
- lispm 14y ago
  That's one idea of the Lisp condition system: you don't return. The handler gets called on error and the full context is still there. The context includes all bindings, dynamic handlers and all possible restarts. The restarts itself are most often generic: Abort, Continue, Use Value, Store Value, ... There can also be several of those. For example the log error could be restarted by using a Abort error to abort a specific action (say, a compilation of a file) , to abort the whole process (say, a compilation of a whole system).
  - qznc 14y ago
    My favored method: return an error object, which includes all the necessary context. Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary.
    - lispm 14y ago
      if you return, you can't continue. With the condition system you implement restarts as a service to the user. You don't have to provide any one. In a typical Lisp system there will be a default handler. The more restarts you implement, the more choice the user may gets. The handler can also decide which and how many restarts it wants to expose to the user, if at all.
    - masklinn 14y ago
      > My favored method: return an error object Right, so you've unwound your whole stack and now the original caller has to re-set the initial conditions (hoping all the state was discarded with the stack and none leaked), alter whatever needs to be changed (assuming and hoping there's even a way to get a handle on that) and re-wind the whole stack from scratch. > Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary. Just as you have to "include all necessary context" in your solution...
- astine 14y ago
  How would you accomplish somthing similar without exposing implementation details? It seems to me "this function may throw these conditions" is more a documentation issue. I think every other system I've seen, (esp C) exposes more details.
- draven 14y ago
  Letting the caller do the handling and giving it access to the dynamic environment where the condition was signaled is a feature. This paper by Pitman helps to understand the design choices www.nhplace.com/kent/Papers/Condition-Handling-2001.html
- masklinn 14y ago
  > You expose implementation details to the outside with those recover points. Of course not, no more than an exception or an error code "exposes implementation details". Condition restarts are part of a library's API, since they're a way for library users to interact with the library (in this case, to customize the handling of some error conditions) > For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it. How and why is it a better behavior, especially if — unlike this contrived example — there are 5 frames of foreign code between the caller and the condition being signalled? Return or exception will have to unwind those frames, the point of a condition is that you don't, instead right there the library can provide a hook through which the library user can respond to the question: "how do I handle [this error]?"
- Jach 14y ago
  Controversial programming opinion of the day: not knowing implementation details will come back to bite you, overexposure is better than underexposure. Anyway, I think the basic idea is just a small extension of being able to pause the program counter, change stuff, do something else, and at one's option continue where one left off, all without requiring a debugger. Nothing new if you've been exposed to the Lisp world. Typical examples of utility being recovering from longComputation() then failing without repeating work and hot-fixing a long-running server process. I agree this example isn't a very good one, I like your design you commented on for this problem better, I think in this case even "an error in parsing a line is not exceptional" would suffice in defeating the example. (Though in Python even syntax errors are implemented with exceptions, so...)
erikb 14y ago
I think you are looking for the "with" statement! The feature you describe is already there. And it works with objects, so it's reusable, extendable and exchangeable if needed. http://effbot.org/zone/python-with-statement.htm http://effbot.org/zone/python-with-statement.htm
- deleted 14y ago
  [deleted]
- masklinn 14y ago
  No, context management is only a small subset of what you can do with condition (and does not involve restart), and also implies stack unwinding (as do exceptions) amongst other things. To TFAA: to talk about conditions but not use lisp syntax, you could have used Smalltalk (the other language with conditions and restarts)
  - erikb 14y ago
    We are not talking "condition" from Lisp here, but the blog post that is linked to this thread. And what the author is doing is asking for a "with" statement without knowing that the feature is already there. "condition" might be a powerful feature and I might even like it myself, but the post doesn't show the power of "condition" to Pythoners, because the feature used in the example already exists in the core language.
    - masklinn 14y ago
      > We are not talking "condition" from Lisp here Of course we are. > And what the author is doing is asking for a "with" statement No, he most definitely is not, a with statement (or Common Lisp's version, `unwind-protect`) does not provide resuming, only restoring a previously-stored context. > the post doesn't show the power of "condition" to Pythoners, because the feature used in the example already exists in the core language. You should try reading the post again rather than stop at the first paragraph, because you're wrong.
howeyc 14y ago
For anyone that had trouble learning the condition system, or just wants another example, this helped me: http://symbo1ics.com/blog/?p=1405 http://symbo1ics.com/blog/?p=1405
- qznc 14y ago
  That task here is: A 'compute-slopes' function gets a list of points and returns a list of slops between consecutive points. The problem: What if points have the same x-value, hence the slope is undefined. Solution 1 Exceptions: throw new DivisionByZero() Solution 2 Condition Handling: provide the restarts point to (a) return nil, (b) return 0, and (c) return a user-specified value. Solution 3 Return Error: return Error("division by zero")
jahewson 14y ago
> why don’t more languages have them? My guess would be that they are not needed. Exceptions for anything other than program death are something of an anti-pattern, potentially spreading the internal details of some piece of code all the way up the stack. My choice of implementation would be to pass a discriminator function which takes an error and returns true if the error is recoverable. Then you have the choice of either returning all the errors at the end or reporting each earlier when the discriminator is called. Edit: That's not to say that exceptions can't be used effectively, they just mostly aren't.
- brudgers 14y ago
  My understanding of Seibel is that Lisp's condition system is designed to avoid exactly the problem of internal details spreading up the stack. It does so by allowing conditions (of which exceptions are one type) to be handled by a higher level of the call stack without unwinding the call stack, and allows for the determination of which particular condition handler to be made independently (and at a higher level of the call stack) than the implementation of the handler. The "anti-pattern" may be a result of the way in which other languages implementation of exception (or condition) handling differs from that of Lisp.
  - jahewson 14y ago
    > [conditions are] handled by a higher level of the call stack without unwinding the call stack, and allow for the determination of which particular condition handler to be made independently (and at a higher level of the call stack) than the implementation of the handler. Is exactly what the higher-order function I described would let you do. Why do we need conditions? Edit: the answer to this question is "because we want to use exceptions". But there's really no need to.
    - brudgers 14y ago
      Per Greenspun's Tenth Rule you do not. http://paulgraham.com/quotes.html http://paulgraham.com/quotes.html
    - 14y ago
brudgers 14y ago
Peter Seibel's explanation in the online version of Practical Common Lisp Chapter 19: http://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://gigamonkeys.com/book/beyond-exception-handling-condit... Practical Common Lisp Table of Contents: http://gigamonkeys.com/book/ http://gigamonkeys.com/book/
ajuc 14y ago
Seems like useful feature to have. Is it supposed to be only used for error handling (like exceptions) or can you use it for unconventional control flow, too?
- masklinn 14y ago
  You can use it for unconventional control flows if you wish to. For instance, see [0] which implements dynamically scoped variables on top of conditions. I'm not sure that's overly common, but I'm a smalltalk dilettante [0] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables http://www.lshift.net/blog/2012/06/27/resumable-exceptions-c...
- ken 14y ago
  Dan Weinreb (one of the Multics users who brought the Multics condition system to Lisp) wrote about why "error" is not a great term: http://danweinreb.org/blog/what-conditions-exceptions-are-really-about http://danweinreb.org/blog/what-conditions-exceptions-are-re... Personally, I've not seen it used for arbitrary control flow. If you control the syntax of things inside your block, then macros are probably good enough. If you're passing values outside of your own block, then you probably need continuations. OTOH, Lisp programmers have a tendency to not care what something is "supposed to be used for". Using Lisp at all is said to be "the most intelligent way to misuse a computer". :-)
ataggart 14y ago
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
- lubutu 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - ataggart 14y ago
    >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: def parseLogInteractively(file): do: return parseLog(file) handle ParseError, e: line = askToFixEntry(e.text) retry That reference to `line` is pretty horrific. 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.

104 points by lubutu 14y ago

qznc 14y ago

What I do not like about this: You expose implementation details to the outside with those recover points. In the same sense exceptions in Java expose implementation details, though. For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it. Basically, I want a more convincing example for condition handling.

lubutu 14y ago
Suppose we were attempting to write parseLogInteractively by just returning errors (as in idiomatic Go). 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 Again we lose the ability to abstract the function 'parseLog'. And I don't know about you, but this looks far worse to me than "resume FixEntry" in terms of exposing implementation details.
- oddthink 14y ago
  In python, I usually deal with this with generators. It's not as elegant as conditions, but it works well enough. I've never tried to permit custom restart-like behavior, but now that generators are coroutines, it should be doable. e.g. def parseEntry(line): try: parsed = foo(line) yield parsed except SomethingBad: yield None Common lisp could really use some better coroutine support (and some way to specify generic sequences). Sure, you can do it with macros, but it gets horrible fast. Have you looked at SERIES, for example?
  - masklinn 14y ago
    > I've never tried to permit custom restart-like behavior, but now that generators are coroutines, it should be doable. 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])
    - oddthink 14y ago
      Thanks for the pointer; I've been learning some Smalltalk lately, but I haven't yet looked into the condition system. 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.
  - praptak 14y ago
    If you want the restart, you need to take advantage of the PEP-342 two-way yield(), as in: ... except SomethingBad: yield None restartRequest = yield None if restartRequest: do whatever is necessary to go on The problem with the above is that the double yield() ugly. You cannot do this with single yield() because the caller would have to know in advance that next() will return None.
  - whism 14y ago
    Generic sequences are coming to common lisp. I'm working on a simple implementation inspired by clojure which I'll be posting to /r/lisp in the coming week.
  - Chris2048 14y ago
    Maybe something like: https://gist.github.com/3598432 https://gist.github.com/3598432 although perhaps passing a 'handlers' object down, with which handler functions could be registered might be better?
- qznc 14y ago
  Do not separate errors and entries. Instead use something like Haskell's Maybe, but instead of an empty Nothing-object you return something which contains error information: def parseLogInteractively(file): entries = list() for line in file: entry = parseEntry(line) if entry.failed: entry = askToFixEntry(entry) entries.append(entry) return entries A design question arises: Do you need to fix parse errors before you can proceed with next entry? If not, the error handling can be done by whomever calls parseLog.
  - lubutu 14y ago
    The abstraction problem remains: you are reimplementing parseLog every time you write a new handler, as I described in section 1. (By the way, you're looking for Haskell's Either type, but ([a],[b]) and [Either a b] are equivalent here.)
    - qznc 14y ago
      No, you only implement this one: def parseLog(file): list = [] for line in file: list.append(parseEntry(line)) return list Or better (more pythonic imho): def parseLog(file): for line in file: yield parseEntry(line) The second version is lazy (if file reading is lazy), so you can even abort parsing or fix the state on an error. Here are your different versions all reusing parseLog from above and equivalent line count to condition handling: 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 (Haskell's Either has "Left a" or "Right b". I want something like "Just value" or "Error msg", but you are right Either is nearer than Maybe)
      - mooism2 14y ago
        (It's conventional to use Left for errors and Right for successes.)
- lmm 14y ago
  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 14y ago
    > 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 14y ago
      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 14y ago
        > 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.
lispm 14y ago
That's one idea of the Lisp condition system: you don't return. The handler gets called on error and the full context is still there. The context includes all bindings, dynamic handlers and all possible restarts. The restarts itself are most often generic: Abort, Continue, Use Value, Store Value, ... There can also be several of those. For example the log error could be restarted by using a Abort error to abort a specific action (say, a compilation of a file) , to abort the whole process (say, a compilation of a whole system).
- qznc 14y ago
  My favored method: return an error object, which includes all the necessary context. Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary.
  - lispm 14y ago
    if you return, you can't continue. With the condition system you implement restarts as a service to the user. You don't have to provide any one. In a typical Lisp system there will be a default handler. The more restarts you implement, the more choice the user may gets. The handler can also decide which and how many restarts it wants to expose to the user, if at all.
  - masklinn 14y ago
    > My favored method: return an error object Right, so you've unwound your whole stack and now the original caller has to re-set the initial conditions (hoping all the state was discarded with the stack and none leaked), alter whatever needs to be changed (assuming and hoping there's even a way to get a handle on that) and re-wind the whole stack from scratch. > Of course, the library writer must anticipate what information might be necessary, but with condition handling he also has to anticipate, what restarts are necessary. Just as you have to "include all necessary context" in your solution...
astine 14y ago
How would you accomplish somthing similar without exposing implementation details? It seems to me "this function may throw these conditions" is more a documentation issue. I think every other system I've seen, (esp C) exposes more details.
draven 14y ago
Letting the caller do the handling and giving it access to the dynamic environment where the condition was signaled is a feature. This paper by Pitman helps to understand the design choices www.nhplace.com/kent/Papers/Condition-Handling-2001.html
masklinn 14y ago
> You expose implementation details to the outside with those recover points. Of course not, no more than an exception or an error code "exposes implementation details". Condition restarts are part of a library's API, since they're a way for library users to interact with the library (in this case, to customize the handling of some error conditions) > For this specific example, the better behavior (imho) would be that parseEntry always returns. So it returns ParseError instead of throwing it. How and why is it a better behavior, especially if — unlike this contrived example — there are 5 frames of foreign code between the caller and the condition being signalled? Return or exception will have to unwind those frames, the point of a condition is that you don't, instead right there the library can provide a hook through which the library user can respond to the question: "how do I handle [this error]?"
Jach 14y ago
Controversial programming opinion of the day: not knowing implementation details will come back to bite you, overexposure is better than underexposure. Anyway, I think the basic idea is just a small extension of being able to pause the program counter, change stuff, do something else, and at one's option continue where one left off, all without requiring a debugger. Nothing new if you've been exposed to the Lisp world. Typical examples of utility being recovering from longComputation() then failing without repeating work and hot-fixing a long-running server process. I agree this example isn't a very good one, I like your design you commented on for this problem better, I think in this case even "an error in parsing a line is not exceptional" would suffice in defeating the example. (Though in Python even syntax errors are implemented with exceptions, so...)

erikb 14y ago

I think you are looking for the "with" statement! The feature you describe is already there. And it works with objects, so it's reusable, extendable and exchangeable if needed. http://effbot.org/zone/python-with-statement.htm http://effbot.org/zone/python-with-statement.htm

deleted 14y ago
[deleted]
masklinn 14y ago
No, context management is only a small subset of what you can do with condition (and does not involve restart), and also implies stack unwinding (as do exceptions) amongst other things. To TFAA: to talk about conditions but not use lisp syntax, you could have used Smalltalk (the other language with conditions and restarts)
- erikb 14y ago
  We are not talking "condition" from Lisp here, but the blog post that is linked to this thread. And what the author is doing is asking for a "with" statement without knowing that the feature is already there. "condition" might be a powerful feature and I might even like it myself, but the post doesn't show the power of "condition" to Pythoners, because the feature used in the example already exists in the core language.
  - masklinn 14y ago
    > We are not talking "condition" from Lisp here Of course we are. > And what the author is doing is asking for a "with" statement No, he most definitely is not, a with statement (or Common Lisp's version, `unwind-protect`) does not provide resuming, only restoring a previously-stored context. > the post doesn't show the power of "condition" to Pythoners, because the feature used in the example already exists in the core language. You should try reading the post again rather than stop at the first paragraph, because you're wrong.

howeyc 14y ago

For anyone that had trouble learning the condition system, or just wants another example, this helped me: http://symbo1ics.com/blog/?p=1405 http://symbo1ics.com/blog/?p=1405

qznc 14y ago
That task here is: A 'compute-slopes' function gets a list of points and returns a list of slops between consecutive points. The problem: What if points have the same x-value, hence the slope is undefined. Solution 1 Exceptions: throw new DivisionByZero() Solution 2 Condition Handling: provide the restarts point to (a) return nil, (b) return 0, and (c) return a user-specified value. Solution 3 Return Error: return Error("division by zero")

jahewson 14y ago

> why don’t more languages have them? My guess would be that they are not needed. Exceptions for anything other than program death are something of an anti-pattern, potentially spreading the internal details of some piece of code all the way up the stack. My choice of implementation would be to pass a discriminator function which takes an error and returns true if the error is recoverable. Then you have the choice of either returning all the errors at the end or reporting each earlier when the discriminator is called. Edit: That's not to say that exceptions can't be used effectively, they just mostly aren't.

brudgers 14y ago
My understanding of Seibel is that Lisp's condition system is designed to avoid exactly the problem of internal details spreading up the stack. It does so by allowing conditions (of which exceptions are one type) to be handled by a higher level of the call stack without unwinding the call stack, and allows for the determination of which particular condition handler to be made independently (and at a higher level of the call stack) than the implementation of the handler. The "anti-pattern" may be a result of the way in which other languages implementation of exception (or condition) handling differs from that of Lisp.
- jahewson 14y ago
  > [conditions are] handled by a higher level of the call stack without unwinding the call stack, and allow for the determination of which particular condition handler to be made independently (and at a higher level of the call stack) than the implementation of the handler. Is exactly what the higher-order function I described would let you do. Why do we need conditions? Edit: the answer to this question is "because we want to use exceptions". But there's really no need to.
  - brudgers 14y ago
    Per Greenspun's Tenth Rule you do not. http://paulgraham.com/quotes.html http://paulgraham.com/quotes.html
  - 14y ago

brudgers 14y ago

Peter Seibel's explanation in the online version of Practical Common Lisp Chapter 19: http://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://gigamonkeys.com/book/beyond-exception-handling-condit... Practical Common Lisp Table of Contents: http://gigamonkeys.com/book/ http://gigamonkeys.com/book/

ajuc 14y ago

Seems like useful feature to have. Is it supposed to be only used for error handling (like exceptions) or can you use it for unconventional control flow, too?

masklinn 14y ago
You can use it for unconventional control flows if you wish to. For instance, see [0] which implements dynamically scoped variables on top of conditions. I'm not sure that's overly common, but I'm a smalltalk dilettante [0] http://www.lshift.net/blog/2012/06/27/resumable-exceptions-can-macro-express-delimited-dynamic-variables http://www.lshift.net/blog/2012/06/27/resumable-exceptions-c...
ken 14y ago
Dan Weinreb (one of the Multics users who brought the Multics condition system to Lisp) wrote about why "error" is not a great term: http://danweinreb.org/blog/what-conditions-exceptions-are-really-about http://danweinreb.org/blog/what-conditions-exceptions-are-re... Personally, I've not seen it used for arbitrary control flow. If you control the syntax of things inside your block, then macros are probably good enough. If you're passing values outside of your own block, then you probably need continuations. OTOH, Lisp programmers have a tendency to not care what something is "supposed to be used for". Using Lisp at all is said to be "the most intelligent way to misuse a computer". :-)

ataggart 14y ago

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

lubutu 14y ago
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.
- deleted 14y ago
  [deleted]
- ataggart 14y ago
  >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: def parseLogInteractively(file): do: return parseLog(file) handle ParseError, e: line = askToFixEntry(e.text) retry That reference to `line` is pretty horrific. 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.