Details on exceptions

[Derek Fountain]

Are the details of the builtin exceptions laid out anywhere? I was looking
though the O'Reilly Nutshell book, which informs me that errors with file
objects raise the builtin exception IOError. However, it doesn't describe
this exception in the same way it describes, for example, the OSError
exception. How do I get the actual error code from IOError of what went
wrong?

I did a search on the Python docs, and couldn't find the information either.
So either the information is well hidden for some reason, or I've missed
some very important information on the standardisation of exception
handling techniques.

 

[John Roth]

Are the details of the builtin exceptions laid out anywhere? I was looking
though the O'Reilly Nutshell book, which informs me that errors with file
objects raise the builtin exception IOError. However, it doesn't describe
this exception in the same way it describes, for example, the OSError
exception. How do I get the actual error code from IOError of what went
wrong?

I did a search on the Python docs, and couldn't find the information either.
So either the information is well hidden for some reason, or I've missed
some very important information on the standardisation of exception
handling techniques.

Library Reference, Built-in Exceptions will tell you
everything you want to know.

John Roth

 

[Derek Fountain]

Library Reference, Built-in Exceptions will tell you

everything you want to know.

Ah ha! Yes, it did, thanks. The business of learning Python seems to revolve
around learning where, in all the documentation, the thing you're looking
for is written.

Here's an example: in that page it says: "When exceptions of this type are
created with a 2-tuple...". Er, what does that mean? I found an example
which does this:

except IOError, (errno, strerror):

which is presumably the syntax referred to. Where, in the docs or the
O'Reilly book, can I find a description of this syntax? Can I instantiate
any class in that manner, or is it somehow specific to the exception
handling in some way?

 

[John Roth]

Ah ha! Yes, it did, thanks. The business of learning Python seems to revolve
around learning where, in all the documentation, the thing you're looking
for is written.

Here's an example: in that page it says: "When exceptions of this type are
created with a 2-tuple...". Er, what does that mean? I found an example
which does this:

except IOError, (errno, strerror):

which is presumably the syntax referred to. Where, in the docs or the
O'Reilly book, can I find a description of this syntax? Can I instantiate
any class in that manner, or is it somehow specific to the exception
handling in some way?

Actually, that's the back end: except is part of the try: except: syntax,
and the second argument is extracting things from the exception
object.

They were put there originally either by the routine that created the
exception object, or by the raise statement. One thing you may be
missing is that an exception object is no different from any other
object, and the creator can stuff any attributes into it that it wants.

John Roth

 

[Derek Fountain]

Actually, that's the back end: except is part of the try: except: syntax,

and the second argument is extracting things from the exception
object.

They were put there originally either by the routine that created the
exception object, or by the raise statement. One thing you may be
missing is that an exception object is no different from any other
object, and the creator can stuff any attributes into it that it wants.

No, I got the "exception is just an object idea". What I don't understand is
the assignment of a tuple in the except clause. I thought the thing after
the exception name is an optional variable name to assign a reference to
the exception object to. The O'Reilly Nutshell book says "The optional
target is an identifier that names a variable that Python binds to the
exception object just before the exception handler executes". This doesn't
make sense in this case:

except IOError, (errno, strerror):

The target is a tuple of 2 variable names so how can it bind "the exception
object" to them? The documentation for try/except says that "the
exception's parameter is assigned to the target". So what, exactly, is an
"exception's parameter"?

 

[Rene Pijlman]

Derek Fountain:

except IOError, (errno, strerror):

The target is a tuple of 2 variable names so how can it bind "the exception
object" to them? The documentation for try/except says that "the
exception's parameter is assigned to the target". So what, exactly, is an
"exception's parameter"?

"For an except clause with an expression, that expression is evaluated,
and the clause matches the exception if the resulting object is
``compatible'' with the exception. An object is compatible with an
exception if it is either the object that identifies the exception, or
(for exceptions that are classes) it is a base class of the exception, or
it is a tuple containing an item that is compatible with the exception."
http://www.python.org/doc/current/ref/try.html#try

I think it has to do with the introduction of exceptions-are-classes in
1.5, and backwards compatibility of older code: "This works because the
tuple-unpack semantics have been loosened to work with any sequence on the
right-hand size (see the section on Sequence Unpacking below), and the
standard exception classes can be accessed like a sequence (by virtue of
their __getitem__ method, see above)."
http://www.python.org/doc/essays/stdexceptions.html

I'd say don't do it. Use exception objects and catch them as objects.

 

[John Roth]

Derek Fountain:

"For an except clause with an expression, that expression is evaluated,
and the clause matches the exception if the resulting object is
``compatible'' with the exception. An object is compatible with an
exception if it is either the object that identifies the exception, or
(for exceptions that are classes) it is a base class of the exception, or
it is a tuple containing an item that is compatible with the exception."
http://www.python.org/doc/current/ref/try.html#try

I think it has to do with the introduction of exceptions-are-classes in
1.5, and backwards compatibility of older code: "This works because the
tuple-unpack semantics have been loosened to work with any sequence on the
right-hand size (see the section on Sequence Unpacking below), and the
standard exception classes can be accessed like a sequence (by virtue of
their __getitem__ method, see above)."
http://www.python.org/doc/essays/stdexceptions.html

I'd say don't do it. Use exception objects and catch them as objects.

I believe the actual answer is that what's assigned is the value of
the 'args' attribute, which is what is specified on the throw statement.
In this case, the args attribute is a tuple of two values - see the
discussion of Exception EnvironmentError (which is the base class
for IOError) in the Library Reference.

In this case, I'd probably agree: I'd capture the actual
exception because it probably contains additional data
like the file name.

John Roth

 

[Stian =?iso-8859-1?Q?S=F8iland?=]

* Derek Fountain spake thusly:

exception object just before the exception handler executes". This doesn't
make sense in this case:
except IOError, (errno, strerror):

Maybe this could illustrate why this works:
.... def __getitem__(self, pos):
.... if pos > 1:
.... raise IndexError
.... return pos
........ raise MyError
.... except Exception, error:
.... (x,y) = error
.... print x
....
0

So if error by any chance implements __getitem__ - the
current case of IOError and actually all Exceptions, values might be
unpacked.

This could even be simplified:
.... raise Exception(5,6)
.... except Exception, (a,b):
.... print a
....
5


Ie. the items of an exceptions are the arguments given when it is
raised. If you know how a exception is raised, ie. that an IOError
always contains two elements, you might unpack.

Remember that what actually happens in this line:
except Exception, error:
is the assignment error = errorInstance

If one instead writes:
except Exception, (a,b):
this simply means assignment unpacking:
(a,b) = errorInstance