Python Forum

i pressed ^C and got:

Output:
Traceback (most recent call last):
  File "tree.py", line 52, in <module>
    names=sorted(listdir(path))
NotADirectoryError: [Errno 20] Not a directory: 'projects/avlmap-0.12.4/CONFIG/readsymlink.c'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "xyzzy.py", line 52, in <module>
    names=sorted(listdir(path))
KeyboardInterrupt

part of the reason for this is that line 52 is in a try: clause, so exceptions are being handled there.

        try:
            names=sorted(listdir(path))
        except:
            names=[]

what if i wanted to specifically handle KeyboardInterrupt in the code that calls this code, and the KeyboardInterrupt happens during the handling of NotADirectoryError, or other kinds of exceptions is cases of other code? will it be able to keep the exceptions apart when there is a handler for each? what if i am doing a recursive call from inside of a try: clause in a recursive function for an asynchronous kind of exception (like KeyboardInterrupt) and two (or more) such exceptions happen together while the recursion is at least two (or more) deep? i am concerned that the nesting of exception events won't always be handled as if they all happened separately.

This is why you declare which exceptions you are trying to catch explicitly, so that other exceptions can propagate as normal:

try:
    names=sorted(listdir(path))
except NotADirectoryError:
    names=[]

i do that in most cases. but this is a case where i want any failure of os.listdir() to be handled. so, i guess, your suggestion means i need to research os.listdir() to find out what all it could raise and list them all on the except.

my real concern is nesting of exception handling, and a 2nd exception being raised (of exactly the same type of exception) before the 1st one completes being handled. could it fall back to the previously defined handler or could it handled as a "during" case? how would a "during" case actually be handled in this kind of situation with regard to running code to handle it? i want to be sure that N exceptions result in the handler code running not only N times, but in the correct order. it seems that by default, an internal try trap in effect during except handling (for it to see the cases of another exception during the handling of one).

The current exception handling was done as PEP 3134. It explains what is going on.

Note that any error coming out of os.listdir() is likely going to be a file error. In 3.x, those are all subclasses of OSError, so you could just try to catch that. It would still be better to target specific errors, though.

what if, in the future, there are new exceptions added that os.listdir() might produce? i can only imagine that they, too, would be subclasses of OSError. so it might be good to have some, but not too much, breadth of scope, catching those errors. so in this case, catching OSError sounds like a reasonable idea.

Skaperen Wrote:what if i wanted to specifically handle KeyboardInterrupt in the code that calls this code, and the KeyboardInterrupt happens during the handling of NotADirectoryError

It doesn't prevent you from catching KeyboardInterrupt.

import os
import time

try:
    try:
        names = sorted(os.listdir('foo.txt'))
    except NotADirectoryError:
        time.sleep(2)
except KeyboardInterrupt as exc:
    print("Hello, I caught KeyboardInterrupt!")

but catching different exceptions happens in different for reasons like wat that piece of code was designed for. the different codes are designed for different purposes by different teams.

Quote:catching different exceptions happens in different for reasons like wat that piece of code was designed for

What you want is not clear. I'm saying that having FooError happen during the handling of BarError doesn't remove any possibilities for the code catching FooError. It is a supplement of information which can potentially be exploited by the code.