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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
