![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 7/4/2017 8:08 PM, Ken Kundert wrote:
On Tue, Jul 04, 2017 at 04:54:11PM -0400, Terry Reedy wrote:
There have been many proposals for what we might call RichExceptions, with more easily access information. But as Raymond Hettinger keeps pointing out, Python does not use exceptions only for (hopefully rare) errors. It also uses them as signals for flow control, both as an alternative form for alternation and for iteration. Alternation with try:except instead of if:else is common. In the try: unicode example above, the NameError is not an error. Until 2.2, IndexError served the role of StopIteration today, and can still be used for iteration. For flow control, richer exceptions just slow code execution.
Terry, Correct me if I am wrong, but this seems like an argument for the proposal.
I actually do not know what 'the proposal' is and how it is the same or different from past proposals, especially those that have been rejected. I initially elaborated on some points of Steven D'Aprano that I agree with, in light of past discussions and tracker issues.
Consider the NameError, currently when raised the error message must be constructed before it is passed to the exception. But in the proposal, you simply pass the name (already available) and the format string (a constant). The name is never interpolated into the format string unless the message is actually used, which it would not in the cases you cite.
That is close to what I am thinking. I would give the format a default value, the one Python uses most often. def NameError(name, template="name {name} not found"): self.name = name self.template = template -- Terry Jan Reedy