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.

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