Guido van Rossum wrote:
The point is not to avoid bare 'except:' from hiding programming
errors. There's no hope to obtain that goal.
The point is to make *legitimate* uses of bare 'except:' easier -- the
typical use case is an application that has some kind of main loop
which uses bare
[Nick Coghlan]
As others have pointed out, GeneratorExit and StopIteration should
never
reach
the job execution loop - if they do, there's a bug in the job, and
they
should
be caught and logged.
Please read my other, detailed post on this (8/5/2005 4:05pm). It is a
mistake to bypass control
The remainder of my message then goes on to describe a hierarchy just
as
you
suggest - SystemError, MemoryError, StopIteration and GeneratorExit
are
all
still caught by except Exception:. The only two exceptions which are
no
longer caught by except Exception: are KeyboardInterrupt and
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
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] 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
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
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?
I say
On Aug 5, 2005, at 2:46 PM, 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
[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
Raymond Hettinger wrote:
2. There is a lesson to be taken from a story in the ACM risks forum
where a massive phone outage was traced to a single line of C code that
ran a break to get out of a nested if-statement. The interesting part
is that this was known to be mission critical code yet
On 8/5/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
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
On 8/5/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
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
12 matches
Mail list logo
