iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-3151.txt
View File

@ -508,12 +508,21 @@ A reference implementation has been started in
http://hg.python.org/features/pep-3151/ in branch ``pep-3151``. http://hg.python.org/features/pep-3151/ in branch ``pep-3151``.
For now only `Step 1`_ is implemented, and without the deprecation warnings. For now only `Step 1`_ is implemented, and without the deprecation warnings.
However, it shows that coalescing the exception types doesn't produce any However, it shows that coalescing the exception types doesn't produce any
significant annoyance in the standard library. The only observed trouble significant annoyance in the standard library.
is with the respective constructors of ``IOError`` and ``WindowsError``,
which are slightly incompatible. The way it is solved is by keeping the The only observed trouble is with the respective constructors of ``IOError``
``IOError`` semantics and adding a fourth optional argument to allow passing and ``WindowsError``, which are slightly incompatible. The way it is solved
the Windows error code (which is different from the POSIX errno). All is by keeping the ``IOError`` semantics and adding a fourth optional argument
``PyErr_SetFromWindowsErr*`` functions do the right thing. 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 Possible alternative