[Python-checkins] r83028 - sandbox/trunk/errnopep/pepXXXX.txt

[antoine.pitrou]

Author: antoine.pitrou
Date: Wed Jul 21 18:12:40 2010
New Revision: 83028

Log:
Explain an example, and put forward the compatibility section



Modified:
   sandbox/trunk/errnopep/pepXXXX.txt

Modified: sandbox/trunk/errnopep/pepXXXX.txt
==============================================================================
--- sandbox/trunk/errnopep/pepXXXX.txt	(original)
+++ sandbox/trunk/errnopep/pepXXXX.txt	Wed Jul 21 18:12:40 2010
@@ -138,7 +138,12 @@
     except OSError:
         pass
 
-What the programmer would like to write instead is something such as::
+``os.remove`` can raise an OSError not only when the file doesn't exist,
+but in other possible situations (for example, the filename points to a
+directory, or the current process doesn't have permission to remove
+the file), which all indicate bugs in the application logic and therefore
+shouldn't be silenced.  What the programmer would like to write instead is
+something such as::
 
     try:
         os.remove(filename)
@@ -146,6 +151,45 @@
         pass
 
 
+Compatibility concerns
+======================
+
+Reworking the exception hierarchy will obviously change the exact semantics
+of at least some existing code.  While it is not possible to improve on the
+current situation without changing exact semantics, it is possible to define
+a narrower type of compatibility, which we will call **useful compatibility**,
+and define as follows:
+
+* *useful compatibility* doesn't make exception catching any narrower, but
+  it can be broader for *naïve* exception-catching code.  Given the following
+  kind of snippet, all exceptions caught before this PEP will also be
+  caught after this PEP, but the reverse may be false::
+  
+      try:
+          os.remove(filename)
+      except OSError:
+          pass
+
+* *useful compatibility* doesn't alter the behaviour of *careful*
+  exception-catching code.  Given the following kind of snippet, the same
+  errors should be silenced or reraised, regardless of whether this PEP
+  has been implemented or not::
+
+      try:
+          os.remove(filename)
+      except OSError as e:
+          if e.errno != errno.ENOENT:
+              raise
+
+The rationale for this compromise is that careless (or "naïve") code
+can't really be helped, but at least code which "works" won't suddenly
+raise errors and crash.  This is important since such code is likely to
+be present in scripts used as cron tasks or automated system administration
+programs.
+
+Careful code should not be penalized.
+
+
 Step 1: coalesce exception types
 ================================
 
@@ -290,45 +334,6 @@
 on the errno value could be exposed for use in pure Python.
 
 
-Compatibility concerns
-======================
-
-Reworking the exception hierarchy will obviously change the exact semantics
-of at least some existing code.  While it is not possible to improve on the
-current situation without changing exact semantics, it is possible to define
-a narrower type of compatibility, which we will call **useful compatibility**,
-and define as follows:
-
-* *useful compatibility* doesn't make exception catching any narrower, but
-  it can be broader for *naïve* exception-catching code.  Given the following
-  kind of snippet, all exceptions caught before this PEP will also be
-  caught after this PEP, but the reverse may be false::
-  
-      try:
-          os.remove(filename)
-      except OSError:
-          pass
-
-* *useful compatibility* doesn't alter the behaviour of *careful*
-  exception-catching code.  Given the following kind of snippet, the same
-  errors should be silenced or reraised, regardless of whether this PEP
-  has been implemented or not::
-
-      try:
-          os.remove(filename)
-      except OSError as e:
-          if e.errno != errno.ENOENT:
-              raise
-
-The rationale for this compromise is that dangerous (or "naïve") code
-can't really be helped, but at least code which "works" won't suddenly
-raise errors and crash.  This is important since such code is likely to
-be present in scripts used as cron tasks or automated system administration
-programs.
-
-Careful code should not be penalized.
-
-
 Possible objections
 ===================