M.-A. Lemburg wrote:
Hi Ram,
I think you are confusing the exception type with the exception reason. By adding 100 more exception types, you don't make things easier, but instead you complicate things, since we'd all have to memorize those 100 exception types.
That said, enhancing the error reasons texts is certainly something that would help everyone.
Adding more exception types to the stack makes sense when there's a dedicated need to catch only specific sub types, but even there it's already possible to add this extra information to the exception objects as e.g. .errno or similar attribute.
There is prior art, though, specifically for errno: $ python2 -c 'open("not-there")' Traceback (most recent call last): File "<string>", line 1, in <module> IOError: [Errno 2] No such file or directory: 'not-there' $ python3 -c 'open("not-there")' Traceback (most recent call last): File "<string>", line 1, in <module> FileNotFoundError: [Errno 2] No such file or directory: 'not-there' I very much prefer the specific exception because most of the time I only want to handle the common problems. Instead of try: open file except OSError as err: if err.errno == what was file-not-found? ah ENOENT: # deal with it elif err.errno == what was is-a-directory? ah EISDIR: # deal with it else: # give up raise I can now write try: open file except FileNotFoundError: # deal with it except IsADirectoryError: # deal with it which (a) looks better to me and (b) is easier to remember. It's a bit like Guido's advice to use distinct functions instead of flags. I am sure that I would quickly adopt more specific exceptions in other areas (most notably HTTPError). I don't think they all need to become built-ins.