[Python-Dev] PEP 348: Exception Reorganization for Python 3.0
Phillip J. Eby
pje 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*
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
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-Dev