On Sun, 05 Dec 2010 01:59:27 +0000, Steven D'Aprano wrote: > Of course, this is mainly of theoretical concern. In practice, "Look > Before You Leap" (test first, then process) is often fine. But there are > traps to look out for. For example, unless you are running a single- > process machine, the following code is subject to race conditions and is > not safe: > > if os.exists(pathname): > fp = open(pathname) > else: > handle_missing_file() > > Just because the file is there when os.exists() looks for it, doesn't > mean it still exists a microsecond later when you try opening it.
I understand this line of thinking. And it makes sense to see why it would matter to leave the exception handling mechanism deal with such issues. > > Or consider this code: > > if y != 0: > result = x/y > else: > handle_division_by_zero() > > > This is also unsafe unless you know the type of y. Suppose y is an > interval quantity that straddles zero, then division by y may fail even > though y != 0. Of course in each of these cases the in-built exceptions are used to verify the result of certain system level or lower level operations. My object was not to deprecate the system-level or other low level exceptions thrown by Python, but to consider whether such a mechanism would be a preferable method of handling your own programs error- conditions. The issue to be considered by every programmer is to define what can be defined as the exceptional condition and what is a condition that merits merely different treatment without causing disruption of the normal flow of the program. -- Harishankar (http://harishankar.org http://lawstudentscommunity.com) -- http://mail.python.org/mailman/listinfo/python-list