[Zope3-dev] avoiding cycles in error-handling code

[Steve Alexander]

Hi David,

<http://lists.zope.org/pipermail/zope3-checkins/2003-January/005767.html>

R. David Murray wrote:
 >
 > I couldn't figure out any purpose being served by the try/finally
 > in Sequence's _validate.  So I added some extra Sequence/Tuple unit
 > tests (previous checkin), and took out the try/finally.  All the
 > tests still pass, so either this code was indeed useless, or no unit
 > test tested that code path.  If someone knows it was not useless,
 > please add a unit test and restore the logic.

      def _validate(self, value):
          super(Sequence, self)._validate(value)
-        try:
-            errors = _validate_sequence(self.value_types, value)
-            if errors:
-                raise ValidationError(WrongContainedType, errors)
+        errors = _validate_sequence(self.value_types, value)
+        if errors:
+            raise ValidationError(WrongContainedType, errors)

-        finally:
-            errors = None


I think the try: finally: in this case is because 'errors' may contain a 
traceback object, or other kinds of 'runtime code representation' 
objects that can make things difficult for the garbage collector.

Here's an example of using a try: finally: with a frame object.

   http://python.org/doc/current/lib/inspect-stack.html


I don't know whether such a thing is necessary in the schema code, though.

Perhaps someone who knows more than I do about good practice in 
garbage-collection when handling errors can help.

--
Steve Alexander