In article <1f7befae04090422024afaee58@mail.gmail.com>,
Tim Peters
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/