I like this idea of having optional exc_{type,val} variables.
| try:
| print kidding
| except NameError:
| try: 1/0
| except:
| print 'sys.exc_type should certainly be a zero-divide here'
| # but what should sys.exc_type be here?
|
| I believe what you sketched would leave me thinking I was staring at a
| divide-by-zero error at the position of the comment. But I still want
| to see a NameError at that point -- the divide by zero is history at
| that point. In nested structures, I always want to see the stuff that's
| relevant to the smallest *enclosing* structure; & at the position of the
| comment, that's the 'try' block that suffered the name error.
|
| A related question, but on a different tack. The following program
| (correctly) dies with an IndexError on the "except elist[i], val:" line:
|
| elist = (None, NameError)
|
| def absurd(i):
| try:
| try:
| 1/0
| except DivideByZeroError: # meant ZeroDivisionError
| print 'caught an exception that doesn\'t exist!'
| except elist[i], val:
| print 'caught the', elist[i], 'error on', val
|
| absurd(2)
|
| The details of that silly code are irrelevant. The *point* is that at
| the time it dies, it's trying to handle an unhandled NameError exception
| from the "except DivideByZeroError" line, while that in turn was trying
| to handle the unhandled ZeroDivisionError.
These two examples suggest to me that it is not easy to define exactly
what the smallest enclosing structure is. Why do you consider the current
behaviour (raising IndexError) correct, whereas in the first example you say
NameError should be the correct exception returned.
I do see your points, but having exceptions set according to where
the code is (e.g in an exception block or a try block) may make the code
difficult to understand, and the compiler could approach the complexity of
Perl ;-)
| I believe Peter Ho's comment leads to the same end here, hence there's
| universal convergence <grin>. One funny side-effect: I believe this
| *implies* that sys.exc_type and sys.exc_value would always be None (or
| unbound, or something else equally vacuous)
Whoops :-)
| > ... folks, speak now or be silent forever! :-)
That's it folks,
Pete.