re-raising an exception in a context handler

Question

From the datamodel docs on context managers:

Note that __exit__() methods should not reraise the passed-in exception; this is the caller’s responsibility.

I have a temporary file, whose file descriptor I'd like to free with close but without writing anything to disk. My intuitive solution was to pass on the exception, but that is discouraged in the docs - and surely for good reasons.

class Processor(object):
    ...
    def write(self, *args, **kwargs):
        if something_bad_happens:
            raise RuntimeError('This format expects %s columns: %s, got %s.' % (
                               (len(self.cols), self.cols, len(args))))
        self.writer.writerow(args)

    def __enter__(self):
        return self

    def __exit__(self, type, value, traceback):
        # the RuntimeError from write will be set as type, value and so on ..
        # I'd like to close the stream here (release the file descriptor), 
        # but I do not leave a trace of the associated file - 
        # (one can always 'manually' delete with `os.remove` but maybe there's a 
        # better way ..?)
        self.output_pipe.close()

Also I do not want in this particular case error handling in the caller for two reasons:

to keep the code in the caller minimal (see below)
the caller is happy with exceptions (fail fast is what we want here)

The context manager is used something like this:

class Worker(object):
    ...
    def run(self):
        # output setup so it will emit a three column CSV
        with self.output().open('w') as output:
            output.write('John', 'CA', 92101)
            output.write('Jane', 'NY', 10304)
            # should yield an error, since only three 'columns' are allowed 
            output.write('Hello', 'world')

update: My quesion was a bit ill-formulated as my problem really boiled down to this: In nested context managers, how can I pass an exception on to the outermost CM?

Did you really mean to close the output twice in `__exit__`? — user2357112, Aug 23 '13 at 08:57
@user2357112, there's more code that I haven't included here - so the code might look terse and maybe difficult to contextualize, sorry for that. Updated my question, I do not close `output_pipe` twice. — miku, Aug 23 '13 at 08:59

unutbu · Accepted Answer · 2013-08-23T09:22:19.260

18

When __exit__ returns True, any exception passed to it is swallowed.
When __exit__ returns False, the exception is reraised.

def __exit__(self, type, value, traceback):
    self.output_pipe.close()  # always close the file
    if type is not None: # an exception has occurred
        os.unlink(...)   # remove the file
        return False     # reraise the exception

You could of course omit the return False since Python will return None (which is Falsish) by default.

By the way, is self.output() an instance of Processor? If so,

with self.output().open('w') as output:

should be

with self.output() as output:

In any case, it would be nicer if you could arrange for the latter to be the correct syntax. You might have to change __enter__ to:

def __enter__(self):
    return self.output_pipe.open('w')

edited Aug 23 '13 at 09:22

answered Aug 23 '13 at 09:12

unutbu

842,883
184
1,785
1,677

Thanks, I guess the `return False` is just want I searched for. – miku Aug 23 '13 at 09:25
3

@miku: *Any* falsey value will do; `None` included; not explicitly returning means `None` is returned and the exception remains raised. – Martijn Pieters Aug 23 '13 at 10:14
1

@MartijnPieters, I see. I find the explicit `False` a bit more reabable at the moment. I have to check the standard library for conventions on this... – miku Aug 23 '13 at 11:26

Martijn Pieters · Answer 2 · 2013-08-23T09:01:05.887

3

There is no need to raise the exception; the exception has already been raised and your context manager is merely being informed of that.

Test if there was no exception instead:

if type is None:
    # if no exception is raised, proceed as usual:
    self.output_pipe.close()

If your context manager were to return True at that moment you'd suppress the exception; just exiting the function instead returns None and the exception remains 'raised'.

Note that the tempfile module includes two types of temporary file objects that act as context managers, that self-delete already, independent of platform. On POSIX systems you can unlink the file right after creation; the file descriptor remains alive until you close the file. Windows offers a 'delete on close' option too. The tempfile.NamedTemporaryFile() class uses the right option for your platform.

edited Aug 23 '13 at 09:01

answered Aug 23 '13 at 08:53

Martijn Pieters

1,048,767
296
4,058
3,343

That looks good and would do what I want, but does it free the resource (file descriptor) of the `output_pipe` which at that moment is an open file in `w` mode? – miku Aug 23 '13 at 08:55
@miku: It appears your code calls `self.output_pipe.close()` **twice**; the second time only when you did not encounter an exception. I merely showed how to handle exceptions. – Martijn Pieters Aug 23 '13 at 08:58
@user2357112: I was demonstrating *how* you'd test if you needed to. – Martijn Pieters Aug 23 '13 at 08:58
@MartijnPieters, no I do not close the `output_pipe` twice, I was just show the two variants (one with and one without error checking). – miku Aug 23 '13 at 09:01
@miku: Right, you don't *need* error checking in this case then. Just clean up *regardless* of the exception being raised. That is what a context manager is *for*. – Martijn Pieters Aug 23 '13 at 09:02
@MartijnPieters, I realize now, that my question is a bit incomplete. Thanks anyway for your answer. – miku Aug 23 '13 at 09:13

re-raising an exception in a context handler

2 Answers2