[Python-Dev] PyExc_UnicodeDecodeError

[Thomas Heller]

"M.-A. Lemburg" <mal at egenix.com> writes:

> Thomas Heller wrote:
>> Can anyone explain why calling this code in a C extension
>> static PyObject *
>> test(PyObject *self, PyObject *arg)
>> {
>>         PyErr_SetString(PyExc_UnicodeDecodeError, "blah blah");
>>         return NULL;
>> }
>> PyMethodDef module_methods[] = {
>>         {"test", test, METH_NOARGS},
>>         {NULL, NULL}
>> };
>> does this (same in 2.3.4, and 2.4 current CVS):
>>
>>>>>from somewhere import test
>>>>>test()
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>> TypeError: function takes exactly 5 arguments (1 given)
>>
>
> See Python/exceptions.c:
>
> PyObject * PyUnicodeDecodeError_Create(
> 	const char *encoding, const char *object, int length,
> 	int start, int end, const char *reason)
> {
>      return PyObject_CallFunction(PyExc_UnicodeDecodeError, "ss#iis",
> 	encoding, object, length, start, end, reason);
> }
>
> This exception is thrown by codecs that want to signal a
> decoding error. It includes the context of the problem as
> well as the reason string.

Thanks, this makes sense.  The real problem I wanted to solve is a
little bit less contrieved ;-)

In this context: I find Exceptions being much too underdocumented.
Not only that a lot of built in exceptions are not listed in 
<http://www.python.org/doc/current/api/standardExceptions.html>,
also I find the description for the exceptions here
<http://www.python.org/dev/doc/devel/lib/module-exceptions.html>
very diffcult to understand, if you want to define a subclass of, for
example, WindowsError for your own code.

A much more interesting and understandable reading is the exceptions.py
module which was last used in 1.5, afaik.

I'm not sure what there can be done about that, maybe keep exceptions.py
in sync (although unused) with the current code, and point to it from
the docs?

Thomas