Mention the rare issue of having a Windows error code exposed as the errno

attribute of a non-WindowsError exception.
This commit is contained in:
Antoine Pitrou 2011-05-10 17:54:07 +02:00
parent e3ee4ff098
commit b6df74e01e
1 changed files with 15 additions and 6 deletions

View File

@ -508,12 +508,21 @@ A reference implementation has been started in
http://hg.python.org/features/pep-3151/ in branch ``pep-3151``.
For now only `Step 1`_ is implemented, and without the deprecation warnings.
However, it shows that coalescing the exception types doesn't produce any
significant annoyance in the standard library. The only observed trouble
is with the respective constructors of ``IOError`` and ``WindowsError``,
which are slightly incompatible. The way it is solved is by keeping the
``IOError`` semantics and adding a fourth optional argument to allow passing
the Windows error code (which is different from the POSIX errno). All
``PyErr_SetFromWindowsErr*`` functions do the right thing.
significant annoyance in the standard library.
The only observed trouble is with the respective constructors of ``IOError``
and ``WindowsError``, which are slightly incompatible. The way it is solved
is by keeping the ``IOError`` semantics and adding a fourth optional argument
to allow passing the Windows error code (which is different from the POSIX errno).
All ``PyErr_SetFromWindowsErr*`` functions do the right thing.
An issue is when the ``PyErr_SetExcFromWindowsErr*`` functions were called
with an exception type which is neither ``WindowsError`` nor a subclass of it:
for example an ``IOError`` whose ``errno`` attribute ended up storing
a Windows error code rather than its POSIX translation - for example
ERROR_BROKEN_PIPE (109) rather than EPIPE (32). Since native Windows error
codes are not exposed by the standard library for matching by third-party code,
such instances should only be found in our own code, and easily fixed.
Possible alternative