Beyond Exception Handling: Conditions and Restarts

Re:Beyond Exception Handling: Conditions and Restarts by IgorPartola on Monday November 14, 2011 @03:47PM (#3235626)

Does this basically mean that CL provides a mechanism that's lower level than what is otherwise equivalent to exceptions/warnings, and that this in turn enables things like restarts? Is this analogous to the relationship between higher level control structures such as if/for/while/break/continue vs the lower-level goto? Lastly, can some of these features not be implemented with exceptions?:

  def parse_log_file(f):
      result = []
      for line in f.readlines(): # Fails for large files
        parsed_line = None
        retries = 0
        while retries < 5:
            try:
                result.append(parse_log_entry(line))
                break
            except MalformedLogEntry:
                line = fix(line)
                retries += 1
      return result

[ Parent | on HN ]

Re:Beyond Exception Handling: Conditions and Restarts by Kototama on Monday November 14, 2011 @03:58PM (#3235664)

Your code is not equivalent. There is a separation of concerns that is possible with conditions/restarts that is not possible with exceptions.

The calling code can choose the appropriate restarts base on information that the callee code does not - and should not - have access to.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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] :).

[ Parent | on HN ]

Re:Beyond Exception Handling: Conditions and Restarts by k_bx on Monday November 14, 2011 @03:59PM (#3235669)

Maybe I misunderstand it, but doesn't "retries" gets increased only on MalformedLogEntries? I mean, if there's no malformed log entries -- how will it ever exit?

[ Parent | on HN ]

Re:Beyond Exception Handling: Conditions and Restarts by IgorPartola on Monday November 14, 2011 @04:01PM (#3235682)

Fixed. I changed how the data is appended to the result half way through writing it so there was no condition to break out of the loop. Now there is a break after the append.

[ Parent | on HN ]