[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.


More information about the Python-Dev mailing list