Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15983 > unrolled thread

Close as Many Files/External resourcs as possible in the face of exceptions

Back to article view | Back to comp.lang.python

Contents

  Close as Many Files/External resourcs as possible in the face of exceptions GZ <zyzhu2000@gmail.com> - 2011-11-20 21:46 -0800
    Re: Close as Many Files/External resourcs as possible in the face of exceptions Mel Wilson <mwilson@the-wire.com> - 2011-11-21 07:09 -0500
      Re: Close as Many Files/External resourcs as possible in the face of exceptions Terry Reedy <tjreedy@udel.edu> - 2011-11-21 16:48 -0500

#15983 — Close as Many Files/External resourcs as possible in the face of exceptions

Hi,

Here is my situation. A parent object owns a list of files (or other
objects with a close() method). The close() method can sometimes fail
and raise an exception. When the parent object's close() method is
called, it needs to close down as many files it owns as possible, even
if the close() function of some files fail. I also want to re-raise at
least one of the original exceptions so that the outer program can
handle it.

What I come up is something like this, suppose L is a list that holds
all the file objects.

is_closed = set()
try:
    for f in L:
        f.close()
        is_closed.add(f)
except:
    try:
        raise #re-raise immediately, keeping context intact
    finally:
        for f in L: # close the rest of the file objects
            if f not in is_closed:
                 try:
                     f.close()
                 except:
                      pass

It will re-raise the first exception and preserve the context and
close as many other files as possible while ignoring any further
exceptions.

But this looks really awkward. And in the case that two files fail to
close, I am not sure the best strategy is to ignore the second
failure.

What is a better way of handling such situation?

Thanks,
gz

[toc] | [next] | [standalone]

#15996

GZ wrote:
> Here is my situation. A parent object owns a list of files (or other
> objects with a close() method). The close() method can sometimes 
fail
> and raise an exception. When the parent object's close() method is
> called, it needs to close down as many files it owns as possible, 
even
> if the close() function of some files fail. I also want to re-raise 
at
> least one of the original exceptions so that the outer program can
> handle it.
[ ... ]
> 
> It will re-raise the first exception and preserve the context and
> close as many other files as possible while ignoring any further
> exceptions.
> 
> But this looks really awkward. And in the case that two files fail 
to
> close, I am not sure the best strategy is to ignore the second
> failure.

I imagine you could save any caught exception instances in a list and 
study them later.

	Mel.

[toc] | [prev] | [next] | [standalone]

#16051

On 11/21/2011 7:09 AM, Mel Wilson wrote:
> GZ wrote:
>> Here is my situation. A parent object owns a list of files (or other
>> objects with a close() method). The close() method can sometimes fail
>> and raise an exception. When the parent object's close() method is
>> called, it needs to close down as many files it owns as possible, even
>> if the close() function of some files fail. I also want to re-raise at
>> least one of the original exceptions so that the outer program can
>> handle it.
> [ ... ]
>>
>> It will re-raise the first exception and preserve the context and
>> close as many other files as possible while ignoring any further
>> exceptions.
>>
>> But this looks really awkward. And in the case that two files fail to
>> close, I am not sure the best strategy is to ignore the second failure.
>
> I imagine you could save any caught exception instances in a list and
> study them later.

Yes, I would raise a custom exception instance that takes such a list of 
failures in its constructor. Give it a custom __str__ method to display 
them all.

-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web