> I don't believe I am ignoring the error.
If you log it and then immediately continue then you are ignoring
it so far as the program is concerned. The logging is only
significant to you after the program completes.
> the error and pick up where it left off and keep going.
> I gather you think that is bad practice, but how bad ?
That depends on how well you know the offending code.
If you are sure that your errors aren't going to propogate
into the rest of the code its OK, but consider this example:
def f()
x() # raises an exception
y()
return 42
def g()
total = z()
return total/result
result = 0
result = f()
g()
Now using your strategy you call f() which raises an exception in
the call to x(). This means that y() is never called - with what
impact?
Also the fumnction f never returns a value so result retains
its initial value of 0.
Now you propose catching the exception, logging it and then continuing
with the call to g(). But g does division with result expecting it to
have been set to a non zero value by f() g will fail with a
ZEroDivision
error.
Thats why its bad practice to carry on regardless, you should try to
identify the cause of the exception and deal with it in your code.
Carrying on execution means you no longer know what state your code
is in and thus its behaviour becomes increasingly unpredictable.
In the worst case you gradually corrupt your data without any obvious
signs of problems so that your entire sysem becomes useless.
> I can go back and decipher what input caused, say, the
> UnboundLocalError, and keep running the rest of my program,
Which is OK if and only if you can be sure that the function
causing the error has no impact on the rest of the program.
And in most programs that is unusual! The conventional
use of try/except is to identify the groups of statements
that are logically linked and wrap them as a block, so that
if any one part fails the whole block fails. In your case it
might look like:
def main()
try:
f()
g()
except SomeError: logit()
try: h()
except AnError: logit()
try:
i()
j()
except AnotherError: logit()
else: return 42
Even ythen I find it hard to conceive of a situation where
you wouldn't want to modify the behaviour based on the occurence
of an error. For example...
> program parses documents from two different sources, ...
> ...What I'd like is if an error is encountered, the
> input (document) that caused the error is logged,
> and the rest of the documents are parsed without stopping
But you wouldn't want a final report to say that the faulty
documents had been parsed, say. So you would use the except
to catch the error and modify some flag to indicate that
errors had been found.
But what you describe sounds like it shouyld be a loop;
Something like:
doclist = getDocuments()
for document in doclist:
try:
parseDocument(document)
reportDocumentResults()
except:
logError()
continue
Now you do the bits for each document and if there is an error
log it and continue to the next document.
Is there any reason why you couldn't structure your code that way?
Alan G
Author of the Learn to Program web tutor
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
