Exceptions' Behaviour
Bernhard Herzog
bh at intevation.de
Thu Jul 26 14:22:14 EDT 2001
quinn at yak.ugcs.caltech.edu (Quinn Dunkan) writes:
> On 19 Jul 2001 11:06:02 -0700, Tom Good <Tom_Good1 at excite.com> wrote:
> >Martin Sj?ren <martin at strakt.com> wrote in message news:<mailman.995526636.21726.python-list at python.org>...
> >> Yes I know that, but that's not what I'm asking. What I'm asking is why i
> >> n
> >>
> >> >>> raise ("a","b")
> >>
> >> the "b" disappears? IMO that's a pretty weird behaviour. Yes anybody usin
> >> g
> >> non-class exceptions derived from Exception in a real-world program are
> >> insane, but this is a puristic thing of mine. :-)
> >>
> >> Martin
> >
> >I agree, it is kind of weird, and I don't know why it works that way.
> >I would probably expect trying to raise a tuple to generate an error.
>
> I expect it's backwards compatibility. Many moons ago there were no
> user-defined classes, and hence no instance exceptions. Ever notice
> the __getitem__ trickiness IOError does so it can be unpacked like
> like a 2-tuple? I have a feeling that once upon a time it was.
AFAIK, these are different things, actually, although they both have to
do with string-based exceptions.
With string exceptions, the exception type is a string and when it is
raised it may have an associated value. For IOError, the value was a
2-tuple. With class-based exceptions, the value is always an instance of
the exception class (or a derived class), but for backwards
compatibility it has to behave like a 1-tuple in some cases.
The raise behavior is related to the trick used to simulated
base-classes for string-based exceptions. If you want to have a common
'baseclass' for exceptions E1 and E2, you simply use the tuple (E1, E2).
You can use that tuple both in except clauses and in raise statements.
Now since exceptions are really strings the raise statement if the
exception type is a tuple takes the first item recursively until it
finds a string.
Bernhard
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://mapit.de/
More information about the Python-list
mailing list