> While we're at weird exception stuff... while aping bits of the
> exception handling code for pypy, I noticed that this should "work",
> and indeed it does:
>
> >>> raise ((((Exception,), 'anything'), 'can', 'go'), 'in here'), 'arg'
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> Exception: arg
>
> Any takers for an explanation?
When there were only string exceptions, I noticed the need for naming
a group of exceptions, e.g.
io_related = (IOError, OSError, socket.SocketError)
try:
<some I/O intense stuff>
except io_related, e:
print "Some kind of I/O related error occurred:", e
So I implemented this. Then (still back in the string exceptions
days) I realized that once something like that is named, it pretty
much behaves like a single exception, so I figured that it should be
possible to raise it as well. This allows "upgrading" an exception
declared in a module to a group of exceptions without breaking code
that raises one of these.
I think the reasoning still holds, but:
(1) The syntax to catch multiple exceptions causes common mistakes
like this:
try:
<some indexing operation>
except KeyError, IndexError:
<error handling>
(2) For upgrading exceptions, multiple inheritance makes more sense.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4