Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 348: Exception Reorganization for Python 3.0
Phillip J. Ebypje at telecommunity.com
Fri Aug 5 21:14:48 CEST 2005
At 02:46 PM 8/5/2005 -0400, Raymond Hettinger wrote:>The PEP moves StopIteration out from under Exception so that it cannot>be caught by a bare except or an explicit "except Exception".>>IMO, this is a mistake. In either form, a programmer is stating that>they want to catch and handle just about anything. There is a>reasonable argument that SystemExit special and should float to the top,>but that is not the case with StopIteration.While I agree with most of your -1's on gratuitous changes, this particular problem isn't gratuitous. A StopIteration that reaches a regular exception handler is a programming error; allowing StopIteration and other control-flow exceptions to be caught other than explicitly *masks* programming errors.Under normal circumstances, StopIteration is caught by for loops or by explicit catches of StopIteration. If it doesn't get caught, *that's* an error, and it would be hidden if caught by a generic "except" clause.So, any code that is "broken" by the move was in fact *already* broken, it's just that one bug (a too-general except: clause) is masking the other bug (the escaping control-flow exception).>When a user creates their own exception for exiting multiple levels of>loops or frames, should they inherit from ControlFlowException on the>theory that it no different in intent from StopIteration or should they>inherit from UserError on the theory that it is a custom exception? Do>you really want routine control-flow exceptions to bypass "except>Exception".Yes, definitely. A control flow exception that isn't explicitly caught somewhere is itself an error, but it's not detectable if it's swallowed by an over-eager except: clause.> I suspect that will lead to coding errors that are very>difficult to spot (it sure looks like it should catch a StopIteration).Actually, no, it makes them *easy* to spot because nothing will catch them, and therefore you will be able to see that there's no handler in place. If they *are* caught, that is what leads to difficult-to-spot errors -- i.e. the situation we have now.>Be careful with these proposals. While well intentioned, they have>ramifications that aren't instantly apparent. Each one needs some deep>thought, user discussion, usability testing, and a darned good reason>for changing what we already have in the field.There is a darned good reason for this one; critical exceptions and control flow exceptions are pretty much the motivating reason for doing any changes to the exception hierarchy at all.
More information about the Python-Devmailing list
[8]ページ先頭