Implicit close() should check for errors

[astrand]

BPO	959379
Nosy	@tim-one, @terryjreedy

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2004-11-07.14:16:36.000>
created_at = <Date 2004-05-24.11:32:13.000>
labels = ['interpreter-core']
title = 'Implicit close() should check for errors'
updated_at = <Date 2004-11-07.14:16:36.000>
user = 'https://bugs.python.org/astrand'

bugs.python.org fields:

activity = <Date 2004-11-07.14:16:36.000>
actor = 'astrand'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-05-24.11:32:13.000>
creator = 'astrand'
dependencies = []
files = []
hgrepos = []
issue_num = 959379
keywords = []
message_count = 5.0
messages = ['20865', '20866', '20867', '20868', '20869']
nosy_count = 3.0
nosy_names = ['tim.peters', 'terry.reedy', 'astrand']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue959379'
versions = ['Python 2.2']

[astrand]

As we all know, the fileobjects destructor invokes the
close() method automatically. But, most people are not
aware of that errors from close() are silently ignored.
This can lead to silent data loss. Consider this example:

$ python -c 'open("foo", "w").write("aaa")'

No traceback or warning message is printed, but the
file is zero bytes large, because the close() system
call returned EDQUOT.

Another similiar example is:

$ python -c 'f=open("foo", "w"); f.write("aaa")'

When using an explicit close(), you get a traceback:

$ python -c 'f=open("foo", "w"); f.write("aaa"); f.close()'
Traceback (most recent call last):
  File "<string>", line 1, in ?
IOError: [Errno 122] Disk quota exceeded

I'm aware of that exceptions cannot be raised in
destructors, but wouldn't it be possible to at least
print a warning message?

[terryjreedy]

Logged In: YES
user_id=593130

I think there are two separate behavior issues: implicit file
close and interpreter shutdown. What happens with
$ python -c 'f=open("foo", "w"); f.write("aaa"); del f'
which forces the implicit close *before* shutdown.

As I recall, the ref manual says little about the shutdown
process, which I believe is necessarily implementation/system
dependent. There certainly is little that can be guaranteed
once the interpreter is partly deconstructed itself.

I'm aware of that exceptions cannot be raised in
destructors, but wouldn't it be possible to at least
print a warning message?

Is there already a runtime warning mechanism, or are you
proposing that one be added?

[astrand]

Logged In: YES
user_id=344921

It has nothing to do with the interpreter shutdown; the same
thing happens for long-lived processed, when the file object
falls off a function end. For example, the code below fails
silently:

def foo():
    f = open("foo", "w")
    f.write("bar")

foo()
time.sleep(1000)

[tim-one]

Logged In: YES
user_id=31435

I think the issue here is mainly that an explicit file.close()
maps to fileobject.c's file_close(), which checks the return
value of the underlying C-level close call and raises an
exception (or not) as appropriate; but file_dealloc(), which is
called as part of recycling garbage fileobjects, does not look
at the return value from the underlying C-level close call it
makes (and, of course, then doesn't raise any exceptions
either based on that return value).

[astrand]

Logged In: YES
user_id=344921

Fixed in revision 2.193 or fileobject.c.