[Python-Dev] PEP 348: Exception Reorganization for Python 3.0

[Phillip J. Eby]

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.