[Python-Dev] Re: Dangerous exceptions (was Re: Another test_compiler mystery)

[David Eppstein]

In article <1f7befae04090422024afaee58 at mail.gmail.com>,
 Tim Peters <tim.peters at gmail.com> wrote:

> Some exceptions should never be suppressed unless named explicitly,
> and a real bitch is that some user-defined exceptions can fit in that
> category too.  The ones that give me (and my employer) the most grief
> are the tree of exceptions deriving from ZODB's ConflictError. 
> ConflictError is a serious thing:  it essentially means the current
> transaction cannot succeed, and the app should give up (and maybe
> retry the current transaction from its start).  Suppressing
> ConflictError by accident-- even inside a hasattr() call! --can
> grossly reduce efficiency, and has a long history too of provoking
> subtle, catastrophic, database corruption bugs.
> 
> I would like to see Python's exception hierarchy grow more
> sophisticated in this respect.  MemoryError, SystemExit, and
> KeyboardInterrupt are things that should not be caught by "except
> Exception:", neither by a bare "except:", nor by hasattr() or C-level
> dict lookup.  ZODB's ConflictError is another of that ilk.  I'd like
> to see "except Exception:" become synonymous with bare "except:", and
> move the "dangerous exceptions" to subclass off a new branch of the
> exception hierarchy.  It could be that something like your patch is
> the only practical way to make this work in the C implementation, so
> I'm keen on it.

It's not really the same subject, but the exception that gives me the 
most grief is StopIteration.  I have to keep remembering to never call 
.next() without catching it; if I forget, I get bugs where some loop 
several levels back in the call tree mysteriously exits.

-- 
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/