[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4