Skip to content

bpo-25381: Update explanation of exceptions in C. #26838

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Nov 15, 2021

Conversation

terryjreedy
Copy link
Member

@terryjreedy terryjreedy commented Jun 21, 2021

This paragraph in extending/extending.rst was unchanged (except for
NULL markup) since committed in 2007 Aug 15 for 2.6 alpha.
Except for there being 3 values, most details have changed.

https://bugs.python.org/issue25381

This paragraph in extending/extending.rst was unchanged (except for
NULL markup) since committed in 2007 Aug 15 for 2.6 alpha.
Comment on lines 130 to 133
(usually a ``NULL`` pointer). Exception information is stored in 3 static
global variables inside the interpreter. The first is the exception type,
or ``NULL`` if no exception has occurred. The second is the exception
instance. The third variable contains the stack
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd write "three" in words instead of "3".

Technically these are not static global variables, they are members of the thread state nowadays.

If no exception occurred all three are none.

I think there are edge cases where the exception type is set but the instance is still NULL.

I also think the traceback may be NULL even though an exception is set (probably it's NULL until the exception bubbles into a Python frame.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'three', 'members', and 'all' done. Otherwise I'm going with the reference to sys.exc_info.

second global variable stores the "associated value" of the exception (the
second argument to :keyword:`raise`). A third variable contains the stack
(usually a ``NULL`` pointer). Exception information is stored in 3 static
global variables inside the interpreter. The first is the exception type,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe "3 static global variables inside the interpreter" --> "3 fields on the interpreter's thread state" ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, using 'members'.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I concur with @iritkatriel, they are not global variables. For example, you can two interpreters, each one has its own exception information.

@terryjreedy wrote "done", but the current PR stil says "3 static global variables".

(usually a ``NULL`` pointer). Exception information is stored in 3 static
global variables inside the interpreter. The first is the exception type,
or ``NULL`` if no exception has occurred. The second is the exception
instance. The third variable contains the stack
traceback in case the error originated in Python code. These three variables
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could originate in C but then go to python and get a traceback, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is, actually, routine, as in IndexError originating in the C list code when executing, for instance, '[][1]'. So the author (apparently Georg Brandl) must have meant something else. I'm deleting the statement.

@terryjreedy terryjreedy requested a review from vstinner June 21, 2021 22:17
@terryjreedy
Copy link
Member Author

The previous variable by variable discussion was mostly about relating the 3 variables to 2.x raise statements. No member by member discussion is needed now, so I deleted it. What the members might be while an exception is being processed by the interpreter is not relevant to users, certainly not for this entry.

Is there a entry that 'thread state' should be linked to?

section on module :mod:`sys` in the Python Library Reference). It is important
(usually -1 or a ``NULL`` pointer). Exception information is stored in
three members of the interpreter's thread state. These are ``NULL`` if
there is no exception. Otherwise they are the C equivalents of the members
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the second can be NULL or None and the third can be NULL in case of non-normalized exception.

The first is the exception type. NULL if no exception.

The second is either the instance of exception, or argument(s) which will be passed to exception constructor on normalization. NULL or None means no arguments. Tuple means several arguments. Otherwise it is a single argument.

The third is a traceback. Can be NULL for non-normalized exceptions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See also PyErr_Fetch, PyErr_Restore and PyErr_NormalizeException. Terminology should be consistent.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying that a Python user of sys.exc_info might see these other value, or that the existing claim of C equivalents is incomplete? I presume the latter. If so, how about this, instead of These are....

If there is no exception, these are NULL. For a normalized exception , these are the C equivalents of the members of the Python tuple returned by :meth:sys.exc_info: the exception type, exception instance, and a traceback object. For a non-normalized exception, the second will be an argument or tuple of arguments that will be passed to the exception on normalization, or NULL or None, meaning "no arguments". The third argument may then be NULL.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems resolved now.

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
@terryjreedy terryjreedy changed the title bpo-25381: Update explanation of exception globals bpo-25381: Update explanation of exceptions in C. Jun 22, 2021
@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Jul 23, 2021
@serhiy-storchaka serhiy-storchaka removed the stale Stale PR or inactive for long period of time. label Jul 23, 2021
section on module :mod:`sys` in the Python Library Reference). It is important
(usually -1 or a ``NULL`` pointer). Exception information is stored in
three members of the interpreter's thread state. These are ``NULL`` if
there is no exception. Otherwise they are the C equivalents of the members
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems resolved now.

@willingc willingc merged commit ad43dc0 into python:main Nov 15, 2021
@miss-islington
Copy link
Contributor

Thanks @terryjreedy for the PR, and @willingc for merging it 🌮🎉.. I'm working now to backport this PR to: 3.9, 3.10.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Nov 15, 2021
* bpo-25381: Update explanation of exception globals

This paragraph in extending/extending.rst was unchanged (except for
NULL markup) since committed in 2007 Aug 15 for 2.6 alpha.

* Respond to reviews and remove duplication.

* Update Doc/extending/extending.rst

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
(cherry picked from commit ad43dc0)

Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Nov 15, 2021
* bpo-25381: Update explanation of exception globals

This paragraph in extending/extending.rst was unchanged (except for
NULL markup) since committed in 2007 Aug 15 for 2.6 alpha.

* Respond to reviews and remove duplication.

* Update Doc/extending/extending.rst

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
(cherry picked from commit ad43dc0)

Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
@bedevere-bot bedevere-bot removed the needs backport to 3.10 only security fixes label Nov 15, 2021
@bedevere-bot
Copy link

GH-29568 is a backport of this pull request to the 3.10 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Nov 15, 2021
@bedevere-bot
Copy link

GH-29569 is a backport of this pull request to the 3.9 branch.

@terryjreedy terryjreedy deleted the extend branch November 15, 2021 23:03
terryjreedy pushed a commit that referenced this pull request Nov 15, 2021
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

(cherry picked from commit ad43dc0)
terryjreedy pushed a commit that referenced this pull request Nov 15, 2021
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

(cherry picked from commit ad43dc0)
remykarem pushed a commit to remykarem/cpython that referenced this pull request Dec 7, 2021
* bpo-25381: Update explanation of exception globals

This paragraph in extending/extending.rst was unchanged (except for
NULL markup) since committed in 2007 Aug 15 for 2.6 alpha.

* Respond to reviews and remove duplication.

* Update Doc/extending/extending.rst

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants