In article <1f7befae04090422024afaee58 at mail.gmail.com>, Tim Peters <tim.peters at gmail.com> wrote: > 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/
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