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

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. PyErrClear() 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 .

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