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

Tim Peters tim.peters at gmail.com
Sun Sep 5 07:02:35 CEST 2004


[Armin Rigo]
> ... Here is a patch attempting to do what I described:
> http://www.python.org/sf/1009929
>
> It's an extension of the asynchronous exception mecanism used to signal
> between threads.  PyErr_Clear() can send some exceptions to its own thread
> using this mecanism.  (So it is thread-safe.)

I'm sorry that I haven't had time to look at this.  But since I didn't
and don't, let's try to complicate it <wink>.

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.


More information about the Python-Dev mailing list