News for hackers. Stuff that matters.
Re:Beyond Exception Handling: Conditions and Restarts by IgorPartola on Monday November 14, 2011 @04:03PM (#3235685)
> The calling code can choose the appropriate restarts base on information that the callee code does not - and should not - have access to.

In the common case, is that not equivalent to the caller catching specific errors by wrapping the callee in a try/except? Could you elaborate?

Re:Beyond Exception Handling: Conditions and Restarts by Kototama on Monday November 14, 2011 @04:09PM (#3235701)
But this is assuming the caller has enough information to solve the problem, which is not always the case (the callee could have information on the structure of the disk that are not relevant to the caller for instance).

Conditions/restarts make a separation of concerns, particularly when the caller knows which of the restart is the more appropriate, if the callee has not enough information/context to choose, and if the callee has more information on how to solve the problem.

I guess the separation can be summarized by: difference between knowing WHAT and HOW to do something. A useful abstraction I guess.

Re:Beyond Exception Handling: Conditions and Restarts by IgorPartola on Monday November 14, 2011 @04:17PM (#3235736)
I see. So this would be somewhat like saying

  except MalformedLogEntry, ex:
      line = fix(line, ex)
and having ex encode the information that fix() needs to do its job?

If that's the case, then I can see the value in having the ability to pass such information around baked into the language. The code I have is growing more and more ugly, and the only way to simplify it is to introduce some kind of a coding convention that is not common to Python.

Re:Beyond Exception Handling: Conditions and Restarts by Kototama on Monday November 14, 2011 @04:22PM (#3235752)
How would you do, in your case, if the parse_log_file function does not know the best strategy if a log file is corrupted? Maybe this information is known only by the caller.

I don't know how to solve that in a language without restarts. The information of what to do could well be asked to the final user (with a dialog box) once an error is catched, the callee would then restart at the point where the execution was interrupted applying the chosen strategy.

EDIT: rereading your Python code, I guess you're right and have the closest equivalent.

Re:Beyond Exception Handling: Conditions and Restarts by IgorPartola on Monday November 14, 2011 @04:40PM (#3235814)
Ah. So the point is that the state of execution of parse_log_entry and everything up the stack from it is frozen, and then an out-of-band exception handler figures out what to do, fixes the condition that caused the error, and resumes from the exact spot where the error was first detected, restarting just the most low-level code block? Man, CL is pretty sweet.

This, by no coincidence I'm sure, reminds me a lot of how signals are handled in UNIX/POSIX. I guess you could simulate this very crudely with those by sending yourself a SIGUSR[1|2] :).