On Aug 21, 2:34 pm, Bruno Desthuilliers <bruno. [EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] a écrit : > > > > > On Aug 19, 4:12 pm, Steven D'Aprano <[EMAIL PROTECTED] > > cybersource.com.au> wrote: > >> On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED] wrote: > >>> def do_something(filename): > >>> if not os.access(filename,os.R_OK): > >>> return err(...) > >>> f = open(filename) > >>> ... > >> You're running on a multitasking modern machine, right? What happens when > >> some other process deletes filename, or changes its permissions, in the > >> time after you check for access but before you actually open it? > > > This is a good point - if you want to use the correct way of opening > > files, and > > you don't want to worry about tracking down exception types, then we > > can probably > > agree that the following is the simplest, easiest-to-remember way: > > > def do_something(filename): > > try: > > f = open(filename) > > except: > > <handle exception> > > ... > > Still not correct IMHO - bare except clauses are BAD. You want: > > try: > f = open(filename) > except IOError, e: > <handle exception> > > > Opening files is a special case where EAFP is the only correct > > solution (AFAIK). I still liberally sprinkle LBYL-style "assert > > isinstance(...)" > > Which defeats the whole point of dynamic typing... > > > and other similar assertions in routines. > > The point > > is that EAFP conflicts with the interest of reporting errors as soon > > as possible (on which much has been written see, for instance Ch. 8 - > > Defensive Programming in Code Complete), > > Defensive programming makes sense in the context of a low-level language > like C where errors can lead to dramatic results. In high-level > languages like Python, the worse thing that an unhandled exception can > cause is an abrupt termination of the process and a nice traceback on > screen. In this context, defensive programming is mostly a waste of time > - if you can't *correctly* handle the exception where it happens, then > doing nothing is the better solution.
Ah... now I understand what the Zen is talking about when it said: "Now is better then never, although never is often better than *right* now." If you don't have all the necessary resources to fix an exception right now, don't try to fix it, instead let it propagate, and allow it to be handled in a level where there is enough information how to fix it. > My 2 cents... Steven D'Aprano says: > Exceptions can and often are anticipated. E.g. if you write code that > opens a URL, you better anticipate that the server might reject your > connection. You better expect to be asked for a cookie, or > authentication. If you check for robots.txt, you better expect that it > might not exist. That's all normal execution. I think we should change except: into expect:, it would confuse less, would it? It signifies that the program expects so and so kinds of exceptional situations. The try: should also be changed to... perhaps in:, block:, onthiscode:, etc (this paragraph is written with my taste buds on the part of my face below my eye and above my jaw) -- http://mail.python.org/mailman/listinfo/python-list