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