improve exception handling notes around lasti - #100467
Conversation
|
@gvanrossum @markshannon following this discussion, I am proposing some improvements to the exception handling notes. |
merwok
changed the title
This change improves the description of the new exception table, focusing on describing the meaning of the lasti flag, and when one should expect it to be set.
317b5bc to
2834cb9
Compare
| Currently, the only opcode that requires the lasti flag to be set is RERAISE. | ||
| That is, if the jump described by an exception table points to an offset where | ||
| a RERAISE (with a non-zero oparg) occurs, the lasti is expected to be on the | ||
| stack, and therefore the lasti flag of the exception table entry must be set. | ||
| The last example gives an illustration of this. The first table entry describes | ||
| a jump where no RERAISE is executed. The second entry describes a jump where a | ||
| RERAISE with oparg 1 is executed. This means that the RERAISE will consume the | ||
| TOS and assume it is the lasti that was pushed when the exception occurred, as | ||
| instructed by the lasti flag. |
There was a problem hiding this comment.
While it's true that the lasti pushed on the stack is intended to be consumed by RESUME, this description lacks clarity on the Python constructs that generate RERAISE. It would be good to show some examples (maybe an exhaustive list) of constructs that do or don't use RERAISE. E.g.
try:
xxx
except Exception:
yyy
does not use RERAISE, but if we replace the last two lines with
finally:
zzz
then we do. IIUC the other construct that uses RERAISE is the with statement, which after __exit__ returns may use RERAISE.
Maybe @iritkatriel or @markshannon can help review this.
|
This PR is stale because it has been open for 30 days with no activity. |
|
This document was moved to |
8 participants
This change improves the description of the new exception table, focusing on describing the meaning of the lasti flag, and when one should expect it to be set.