Exception handling in Python 3.x

[Hrvoje Niksic]

Peter Otten <__peter__ at web.de> writes:

>> Note that StopIteration is an internal detail of no relevance whatsoever
>> to the caller. Expose this is unnecessary at best and confusing at worst.
>
> http://mail.python.org/pipermail/python-list/2010-October/1258606.html
> http://mail.python.org/pipermail/python-list/2010-October/1259024.html

Both of these involve suppressing the chaining at the wrong place,
namely in the outer handler or, worse yet, in the exception display
mechanism.  Steven, on the other hand, wants his *inner* handler to
express that the original exception was an implementation detail, a
business exception such as StopIteration, that is completely irrelevant
to the actual exception being raised.  The outer handler is the wrong
place to suppress the chaining because it has no way of distinguishing
Steven's case from a genuine case of a new exception unexpectedly
occurring during handling of the original exception.

One solution would be for "raise" inside except to not use the context.
For example:

try:
  {}[1]
except KeyError:
  1/0

would behave as before, but:

But:

try:
  {}[1]
except KeyError:
  raise Exception("my error")

...would raise the custom error forgetting the KeyError.