[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