[Python-Dev] FormatError() in callproc.c under win32
Thomas Heller
theller at ctypes.org
Mon Jan 26 21:12:18 CET 2009
Ulrich Eckhardt schrieb:
> Hi!
>
> In callproc.c from trunk is a function called SetException(), which calls
> FormatError() only to discard the contents. Can anyone enlighten me to the
> reasons thereof? Is it just to check if the errorcode is registered in the
> stringtables?
I think that your guess is somewhat similar to what I thought when I
wrote the code.
>
> The reason I ask is the CE port. The FormatMessage API exists there (or,
> rather, the FormatMessageW API), but the tables containing the error messages
> are optional for the OS and for space reasons many vendors chose not to
> include them. That means that the function there regularly fails to retrieve
> the requested string.
>
> My first approach was to fall back to simply providing a sting with a numeric
> representation of the errorcode, but that would change the meaning of above
> function, because then it could never fails.
>
> My second approach was to enhance PyErr_SetFromWindowsErr() to handle the
> additional error codes that are checked in SetException(). However, those
> require more context than just the error code, they use the EXCEPTION_RECORD
> passed to SetException() for that.
>
> My third approach would be to filter out the special error codes first and
> delegate all others to PyErr_SetFromWindowsErr(). The latter already handles
> the lack of a string for the code by formatting it numerically. This would
> also improve consistency, since the two functions use different ways to
> format unrecognised errors numerically. This approach would change where and
> how a completely unrecognised error code is formatted, but would otherwise be
> pretty equivalent.
The third approach is fine with me. Sidenote: The only error codes that I remember
having seen in practice are 'access violation reading...' and 'access violation writing...',
although it may be that on WinCE 'datatype misalignment' may also be possible.
--
Thanks,
Thomas
More information about the Python-Dev
mailing list