exception handling in complex Python programs

[Lie]

On Aug 21, 2:34 pm, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> dbpoko... at gmail.com a écrit :
>
>
>
> > On Aug 19, 4:12 pm, Steven D'Aprano <st... at REMOVE-THIS-
> > cybersource.com.au> wrote:
> >> On Tue, 19 Aug 2008 11:07:39 -0700, dbpoko... at gmail.com 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)