Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit dd909db

Browse files
committed
#10058: tweak wording about exception returns.
1 parent 17ef0d5 commit dd909db

1 file changed

Lines changed: 10 additions & 9 deletions

File tree

Doc/c-api/intro.rst

Lines changed: 10 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -361,15 +361,16 @@ traceback.
361361

362362
.. index:: single: PyErr_Occurred()
363363

364-
For C programmers, however, error checking always has to be explicit. All
365-
functions in the Python/C API can raise exceptions, unless an explicit claim is
366-
made otherwise in a function's documentation. In general, when a function
367-
encounters an error, it sets an exception, discards any object references that
368-
it owns, and returns an error indicator --- usually *NULL* or ``-1``. A few
369-
functions return a Boolean true/false result, with false indicating an error.
370-
Very few functions return no explicit error indicator or have an ambiguous
371-
return value, and require explicit testing for errors with
372-
:c:func:`PyErr_Occurred`.
364+
For C programmers, however, error checking always has to be explicit. All
365+
functions in the Python/C API can raise exceptions, unless an explicit claim is
366+
made otherwise in a function's documentation. In general, when a function
367+
encounters an error, it sets an exception, discards any object references that
368+
it owns, and returns an error indicator. If not documented otherwise, this
369+
indicator is either *NULL* or ``-1``, depending on the function's return type.
370+
A few functions return a Boolean true/false result, with false indicating an
371+
error. Very few functions return no explicit error indicator or have an
372+
ambiguous return value, and require explicit testing for errors with
373+
:c:func:`PyErr_Occurred`. These exceptions are always explicitly documented.
373374

374375
.. index::
375376
single: PyErr_SetString()

0 commit comments

Comments
 (0)