cleanup after exceptions

[Padraig]

Hi,

I'm a little confused why objects
are not deleted after they go
out of scope due to an exception?

For e.g.


The file is not written/closed until
the python interpreter exits.
The same thing applies to other objects.

cheers,
Pádraig.

 

[Jp Calderone]

Hi,

I'm a little confused why objects
are not deleted after they go
out of scope due to an exception?

Because objects don't go out of scope. Only variables do. Objects remain
"alive" as long as there are any references to them.

For e.g.



The file is not written/closed until
the python interpreter exits.
The same thing applies to other objects.

In this case, the traceback still holds a reference to the frame from
which the exception was raised, which itself holds a reference to all the
locales from that function.

Calling sys.exc_clear() (possibly followed by gc.collect()) should force
the cleanup you expect.

Jp

 

[Padraig]

Because objects don't go out of scope. Only variables do. Objects remain
"alive" as long as there are any references to them.




In this case, the traceback still holds a reference to the frame from
which the exception was raised,

OK I can see that, but why doesn't a pass on the exception release it?
This is demonstrated with:

#!/usr/bin/env python

import time

class c:
def __del__(self):
print "del"

def f():
C=c()
exception=throw

try:
f()
except:
pass

time.sleep(3)

which itself holds a reference to all the
locales from that function.

don't know what you mean by this

Calling sys.exc_clear()

This isn't in version 2.2.2 at least

(possibly followed by gc.collect()) should force
the cleanup you expect.

thanks,
Pádraig.

 

[Padraig]

Because objects don't go out of scope. Only variables do. Objects remain
"alive" as long as there are any references to them.




In this case, the traceback still holds a reference to the frame from
which the exception was raised

OK I can see that, but why doesn't a pass on the exception release it?
This is demonstrated with:

#!/usr/bin/env python

import time

class c:
def __del__(self):
print "del"

def f():
C=c()
exception=throw

try:
f()
except:
pass

time.sleep(3)

> which itself holds a reference to all the
> locales from that function.

don't know what you mean by this

>
> Calling sys.exc_clear()

This isn't in version 2.2.2 at least

> (possibly followed by gc.collect()) should force
> the cleanup you expect.

thanks,
Pádraig.

 

[Peter Otten]

Because objects don't go out of scope. Only variables do. Objects
remain
"alive" as long as there are any references to them.


In this case, the traceback still holds a reference to the frame from
which the exception was raised, which itself holds a reference to all the
locales from that function.

Calling sys.exc_clear() (possibly followed by gc.collect()) should force
the cleanup you expect.

I tried out your recipe, but with no luck:

Python 2.3.2 (#1, Oct 21 2003, 10:03:19)
[GCC 3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information..... def __del__(self):
.... print "now i'm gone"
........ t = T()
.... raise Exception
....Traceback (most recent call last):
File "<stdin>", line 1, in ?
0

The only way to clear the reference I've found so far is a bit unorthodox:
now i'm gone
Traceback (most recent call last):
File "<stdin>", line 1, in ?
Exception

There seems to be some dark corner of the exception infrastructure that
exc_clear() doesn't touch.

However, I think it's about time to direct the OP to the solution of the
"real" problem, i. e. ensuring that a resource is released when an
exception occurs:
.... t = T()
.... try:
.... raise Exception
.... finally:
.... del t
....now i'm gone
Traceback (most recent call last):
File "<stdin>", line 1, in ?

Whether immediate garbage collection occurs, is an implementation detail.
The code will be more portable if try...finally is used in such cases.

Peter