source: python/trunk/Doc/c-api/exceptions.rst

Last change on this file was 391, checked in by dmik, 11 years ago

python: Merge vendor 2.7.6 to trunk.

  • Property svn:eol-style set to native
File size: 29.2 KB
RevLine 
[2]1.. highlightlang:: c
2
3
4.. _exceptionhandling:
5
6******************
7Exception Handling
8******************
9
10The functions described in this chapter will let you handle and raise Python
11exceptions. It is important to understand some of the basics of Python
[391]12exception handling. It works somewhat like the Unix :c:data:`errno` variable:
[2]13there is a global indicator (per thread) of the last error that occurred. Most
14functions don't clear this on success, but will set it to indicate the cause of
15the error on failure. Most functions also return an error indicator, usually
16*NULL* if they are supposed to return a pointer, or ``-1`` if they return an
[391]17integer (exception: the :c:func:`PyArg_\*` functions return ``1`` for success and
[2]18``0`` for failure).
19
20When a function must fail because some function it called failed, it generally
21doesn't set the error indicator; the function it called already set it. It is
22responsible for either handling the error and clearing the exception or
23returning after cleaning up any resources it holds (such as object references or
24memory allocations); it should *not* continue normally if it is not prepared to
25handle the error. If returning due to an error, it is important to indicate to
26the caller that an error has been set. If the error is not handled or carefully
27propagated, additional calls into the Python/C API may not behave as intended
28and may fail in mysterious ways.
29
30.. index::
31 single: exc_type (in module sys)
32 single: exc_value (in module sys)
33 single: exc_traceback (in module sys)
34
35The error indicator consists of three Python objects corresponding to the
36Python variables ``sys.exc_type``, ``sys.exc_value`` and ``sys.exc_traceback``.
37API functions exist to interact with the error indicator in various ways. There
38is a separate error indicator for each thread.
39
40.. XXX Order of these should be more thoughtful.
41 Either alphabetical or some kind of structure.
42
43
[391]44.. c:function:: void PyErr_PrintEx(int set_sys_last_vars)
[2]45
46 Print a standard traceback to ``sys.stderr`` and clear the error indicator.
47 Call this function only when the error indicator is set. (Otherwise it will
48 cause a fatal error!)
49
50 If *set_sys_last_vars* is nonzero, the variables :data:`sys.last_type`,
51 :data:`sys.last_value` and :data:`sys.last_traceback` will be set to the
52 type, value and traceback of the printed exception, respectively.
53
54
[391]55.. c:function:: void PyErr_Print()
[2]56
57 Alias for ``PyErr_PrintEx(1)``.
58
59
[391]60.. c:function:: PyObject* PyErr_Occurred()
[2]61
62 Test whether the error indicator is set. If set, return the exception *type*
[391]63 (the first argument to the last call to one of the :c:func:`PyErr_Set\*`
64 functions or to :c:func:`PyErr_Restore`). If not set, return *NULL*. You do not
65 own a reference to the return value, so you do not need to :c:func:`Py_DECREF`
[2]66 it.
67
68 .. note::
69
70 Do not compare the return value to a specific exception; use
[391]71 :c:func:`PyErr_ExceptionMatches` instead, shown below. (The comparison could
[2]72 easily fail since the exception may be an instance instead of a class, in the
73 case of a class exception, or it may the a subclass of the expected exception.)
74
75
[391]76.. c:function:: int PyErr_ExceptionMatches(PyObject *exc)
[2]77
78 Equivalent to ``PyErr_GivenExceptionMatches(PyErr_Occurred(), exc)``. This
79 should only be called when an exception is actually set; a memory access
80 violation will occur if no exception has been raised.
81
82
[391]83.. c:function:: int PyErr_GivenExceptionMatches(PyObject *given, PyObject *exc)
[2]84
85 Return true if the *given* exception matches the exception in *exc*. If
86 *exc* is a class object, this also returns true when *given* is an instance
87 of a subclass. If *exc* is a tuple, all exceptions in the tuple (and
88 recursively in subtuples) are searched for a match.
89
90
[391]91.. c:function:: void PyErr_NormalizeException(PyObject**exc, PyObject**val, PyObject**tb)
[2]92
[391]93 Under certain circumstances, the values returned by :c:func:`PyErr_Fetch` below
[2]94 can be "unnormalized", meaning that ``*exc`` is a class object but ``*val`` is
95 not an instance of the same class. This function can be used to instantiate
96 the class in that case. If the values are already normalized, nothing happens.
97 The delayed normalization is implemented to improve performance.
98
99
[391]100.. c:function:: void PyErr_Clear()
[2]101
102 Clear the error indicator. If the error indicator is not set, there is no
103 effect.
104
105
[391]106.. c:function:: void PyErr_Fetch(PyObject **ptype, PyObject **pvalue, PyObject **ptraceback)
[2]107
108 Retrieve the error indicator into three variables whose addresses are passed.
109 If the error indicator is not set, set all three variables to *NULL*. If it is
110 set, it will be cleared and you own a reference to each object retrieved. The
111 value and traceback object may be *NULL* even when the type object is not.
112
113 .. note::
114
115 This function is normally only used by code that needs to handle exceptions or
116 by code that needs to save and restore the error indicator temporarily.
117
118
[391]119.. c:function:: void PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback)
[2]120
121 Set the error indicator from the three objects. If the error indicator is
122 already set, it is cleared first. If the objects are *NULL*, the error
123 indicator is cleared. Do not pass a *NULL* type and non-*NULL* value or
124 traceback. The exception type should be a class. Do not pass an invalid
125 exception type or value. (Violating these rules will cause subtle problems
126 later.) This call takes away a reference to each object: you must own a
127 reference to each object before the call and after the call you no longer own
128 these references. (If you don't understand this, don't use this function. I
129 warned you.)
130
131 .. note::
132
133 This function is normally only used by code that needs to save and restore the
[391]134 error indicator temporarily; use :c:func:`PyErr_Fetch` to save the current
[2]135 exception state.
136
137
[391]138.. c:function:: void PyErr_SetString(PyObject *type, const char *message)
[2]139
140 This is the most common way to set the error indicator. The first argument
141 specifies the exception type; it is normally one of the standard exceptions,
[391]142 e.g. :c:data:`PyExc_RuntimeError`. You need not increment its reference count.
[2]143 The second argument is an error message; it is converted to a string object.
144
145
[391]146.. c:function:: void PyErr_SetObject(PyObject *type, PyObject *value)
[2]147
[391]148 This function is similar to :c:func:`PyErr_SetString` but lets you specify an
[2]149 arbitrary Python object for the "value" of the exception.
150
151
[391]152.. c:function:: PyObject* PyErr_Format(PyObject *exception, const char *format, ...)
[2]153
[391]154 This function sets the error indicator and returns *NULL*. *exception*
155 should be a Python exception class. The *format* and subsequent
156 parameters help format the error message; they have the same meaning and
157 values as in :c:func:`PyString_FromFormat`.
[2]158
159
[391]160.. c:function:: void PyErr_SetNone(PyObject *type)
[2]161
162 This is a shorthand for ``PyErr_SetObject(type, Py_None)``.
163
164
[391]165.. c:function:: int PyErr_BadArgument()
[2]166
167 This is a shorthand for ``PyErr_SetString(PyExc_TypeError, message)``, where
168 *message* indicates that a built-in operation was invoked with an illegal
169 argument. It is mostly for internal use.
170
171
[391]172.. c:function:: PyObject* PyErr_NoMemory()
[2]173
174 This is a shorthand for ``PyErr_SetNone(PyExc_MemoryError)``; it returns *NULL*
175 so an object allocation function can write ``return PyErr_NoMemory();`` when it
176 runs out of memory.
177
178
[391]179.. c:function:: PyObject* PyErr_SetFromErrno(PyObject *type)
[2]180
181 .. index:: single: strerror()
182
183 This is a convenience function to raise an exception when a C library function
[391]184 has returned an error and set the C variable :c:data:`errno`. It constructs a
185 tuple object whose first item is the integer :c:data:`errno` value and whose
186 second item is the corresponding error message (gotten from :c:func:`strerror`),
[2]187 and then calls ``PyErr_SetObject(type, object)``. On Unix, when the
[391]188 :c:data:`errno` value is :const:`EINTR`, indicating an interrupted system call,
189 this calls :c:func:`PyErr_CheckSignals`, and if that set the error indicator,
[2]190 leaves it set to that. The function always returns *NULL*, so a wrapper
191 function around a system call can write ``return PyErr_SetFromErrno(type);``
192 when the system call returns an error.
193
194
[391]195.. c:function:: PyObject* PyErr_SetFromErrnoWithFilenameObject(PyObject *type, PyObject *filenameObject)
[2]196
[391]197 Similar to :c:func:`PyErr_SetFromErrno`, with the additional behavior that if
198 *filenameObject* is not *NULL*, it is passed to the constructor of *type* as
199 a third parameter. In the case of exceptions such as :exc:`IOError` and
200 :exc:`OSError`, this is used to define the :attr:`filename` attribute of the
201 exception instance.
[2]202
203
[391]204.. c:function:: PyObject* PyErr_SetFromErrnoWithFilename(PyObject *type, const char *filename)
[2]205
[391]206 Similar to :c:func:`PyErr_SetFromErrnoWithFilenameObject`, but the filename
207 is given as a C string.
208
209
210.. c:function:: PyObject* PyErr_SetFromWindowsErr(int ierr)
211
[2]212 This is a convenience function to raise :exc:`WindowsError`. If called with
[391]213 *ierr* of :c:data:`0`, the error code returned by a call to :c:func:`GetLastError`
214 is used instead. It calls the Win32 function :c:func:`FormatMessage` to retrieve
215 the Windows description of error code given by *ierr* or :c:func:`GetLastError`,
[2]216 then it constructs a tuple object whose first item is the *ierr* value and whose
217 second item is the corresponding error message (gotten from
[391]218 :c:func:`FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
[2]219 object)``. This function always returns *NULL*. Availability: Windows.
220
221
[391]222.. c:function:: PyObject* PyErr_SetExcFromWindowsErr(PyObject *type, int ierr)
[2]223
[391]224 Similar to :c:func:`PyErr_SetFromWindowsErr`, with an additional parameter
[2]225 specifying the exception type to be raised. Availability: Windows.
226
227 .. versionadded:: 2.3
228
229
[391]230.. c:function:: PyObject* PyErr_SetFromWindowsErrWithFilenameObject(int ierr, PyObject *filenameObject)
[2]231
[391]232 Similar to :c:func:`PyErr_SetFromWindowsErr`, with the additional behavior that
233 if *filenameObject* is not *NULL*, it is passed to the constructor of
[2]234 :exc:`WindowsError` as a third parameter. Availability: Windows.
235
236
[391]237.. c:function:: PyObject* PyErr_SetFromWindowsErrWithFilename(int ierr, const char *filename)
[2]238
[391]239 Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, but the
240 filename is given as a C string. Availability: Windows.
241
242
243.. c:function:: PyObject* PyErr_SetExcFromWindowsErrWithFilenameObject(PyObject *type, int ierr, PyObject *filename)
244
245 Similar to :c:func:`PyErr_SetFromWindowsErrWithFilenameObject`, with an
246 additional parameter specifying the exception type to be raised.
247 Availability: Windows.
248
249 .. versionadded:: 2.3
250
251
252.. c:function:: PyObject* PyErr_SetExcFromWindowsErrWithFilename(PyObject *type, int ierr, const char *filename)
253
254 Similar to :c:func:`PyErr_SetFromWindowsErrWithFilename`, with an additional
[2]255 parameter specifying the exception type to be raised. Availability: Windows.
256
257 .. versionadded:: 2.3
258
259
[391]260.. c:function:: void PyErr_BadInternalCall()
[2]261
262 This is a shorthand for ``PyErr_SetString(PyExc_SystemError, message)``,
263 where *message* indicates that an internal operation (e.g. a Python/C API
264 function) was invoked with an illegal argument. It is mostly for internal
265 use.
266
267
[391]268.. c:function:: int PyErr_WarnEx(PyObject *category, char *message, int stacklevel)
[2]269
270 Issue a warning message. The *category* argument is a warning category (see
271 below) or *NULL*; the *message* argument is a message string. *stacklevel* is a
272 positive number giving a number of stack frames; the warning will be issued from
273 the currently executing line of code in that stack frame. A *stacklevel* of 1
[391]274 is the function calling :c:func:`PyErr_WarnEx`, 2 is the function above that,
[2]275 and so forth.
276
277 This function normally prints a warning message to *sys.stderr*; however, it is
278 also possible that the user has specified that warnings are to be turned into
279 errors, and in that case this will raise an exception. It is also possible that
280 the function raises an exception because of a problem with the warning machinery
281 (the implementation imports the :mod:`warnings` module to do the heavy lifting).
282 The return value is ``0`` if no exception is raised, or ``-1`` if an exception
283 is raised. (It is not possible to determine whether a warning message is
284 actually printed, nor what the reason is for the exception; this is
285 intentional.) If an exception is raised, the caller should do its normal
[391]286 exception handling (for example, :c:func:`Py_DECREF` owned references and return
[2]287 an error value).
288
[391]289 Warning categories must be subclasses of :c:data:`Warning`; the default warning
290 category is :c:data:`RuntimeWarning`. The standard Python warning categories are
[2]291 available as global variables whose names are ``PyExc_`` followed by the Python
[391]292 exception name. These have the type :c:type:`PyObject\*`; they are all class
293 objects. Their names are :c:data:`PyExc_Warning`, :c:data:`PyExc_UserWarning`,
294 :c:data:`PyExc_UnicodeWarning`, :c:data:`PyExc_DeprecationWarning`,
295 :c:data:`PyExc_SyntaxWarning`, :c:data:`PyExc_RuntimeWarning`, and
296 :c:data:`PyExc_FutureWarning`. :c:data:`PyExc_Warning` is a subclass of
297 :c:data:`PyExc_Exception`; the other warning categories are subclasses of
298 :c:data:`PyExc_Warning`.
[2]299
300 For information about warning control, see the documentation for the
301 :mod:`warnings` module and the :option:`-W` option in the command line
302 documentation. There is no C API for warning control.
303
304
[391]305.. c:function:: int PyErr_Warn(PyObject *category, char *message)
[2]306
307 Issue a warning message. The *category* argument is a warning category (see
308 below) or *NULL*; the *message* argument is a message string. The warning will
[391]309 appear to be issued from the function calling :c:func:`PyErr_Warn`, equivalent to
310 calling :c:func:`PyErr_WarnEx` with a *stacklevel* of 1.
[2]311
[391]312 Deprecated; use :c:func:`PyErr_WarnEx` instead.
[2]313
314
[391]315.. c:function:: int PyErr_WarnExplicit(PyObject *category, const char *message, const char *filename, int lineno, const char *module, PyObject *registry)
[2]316
317 Issue a warning message with explicit control over all warning attributes. This
318 is a straightforward wrapper around the Python function
319 :func:`warnings.warn_explicit`, see there for more information. The *module*
320 and *registry* arguments may be set to *NULL* to get the default effect
321 described there.
322
323
[391]324.. c:function:: int PyErr_WarnPy3k(char *message, int stacklevel)
[2]325
326 Issue a :exc:`DeprecationWarning` with the given *message* and *stacklevel*
[391]327 if the :c:data:`Py_Py3kWarningFlag` flag is enabled.
[2]328
329 .. versionadded:: 2.6
330
331
[391]332.. c:function:: int PyErr_CheckSignals()
[2]333
334 .. index::
335 module: signal
336 single: SIGINT
337 single: KeyboardInterrupt (built-in exception)
338
339 This function interacts with Python's signal handling. It checks whether a
340 signal has been sent to the processes and if so, invokes the corresponding
341 signal handler. If the :mod:`signal` module is supported, this can invoke a
342 signal handler written in Python. In all cases, the default effect for
343 :const:`SIGINT` is to raise the :exc:`KeyboardInterrupt` exception. If an
344 exception is raised the error indicator is set and the function returns ``-1``;
345 otherwise the function returns ``0``. The error indicator may or may not be
346 cleared if it was previously set.
347
348
[391]349.. c:function:: void PyErr_SetInterrupt()
[2]350
351 .. index::
352 single: SIGINT
353 single: KeyboardInterrupt (built-in exception)
354
355 This function simulates the effect of a :const:`SIGINT` signal arriving --- the
[391]356 next time :c:func:`PyErr_CheckSignals` is called, :exc:`KeyboardInterrupt` will
[2]357 be raised. It may be called without holding the interpreter lock.
358
359 .. % XXX This was described as obsolete, but is used in
360 .. % thread.interrupt_main() (used from IDLE), so it's still needed.
361
362
[391]363.. c:function:: int PySignal_SetWakeupFd(int fd)
[2]364
365 This utility function specifies a file descriptor to which a ``'\0'`` byte will
366 be written whenever a signal is received. It returns the previous such file
367 descriptor. The value ``-1`` disables the feature; this is the initial state.
368 This is equivalent to :func:`signal.set_wakeup_fd` in Python, but without any
369 error checking. *fd* should be a valid file descriptor. The function should
370 only be called from the main thread.
371
[391]372 .. versionadded:: 2.6
[2]373
374
[391]375.. c:function:: PyObject* PyErr_NewException(char *name, PyObject *base, PyObject *dict)
376
377 This utility function creates and returns a new exception class. The *name*
[2]378 argument must be the name of the new exception, a C string of the form
[391]379 ``module.classname``. The *base* and *dict* arguments are normally *NULL*.
380 This creates a class object derived from :exc:`Exception` (accessible in C as
381 :c:data:`PyExc_Exception`).
[2]382
383 The :attr:`__module__` attribute of the new class is set to the first part (up
384 to the last dot) of the *name* argument, and the class name is set to the last
385 part (after the last dot). The *base* argument can be used to specify alternate
386 base classes; it can either be only one class or a tuple of classes. The *dict*
387 argument can be used to specify a dictionary of class variables and methods.
388
389
[391]390.. c:function:: PyObject* PyErr_NewExceptionWithDoc(char *name, char *doc, PyObject *base, PyObject *dict)
[2]391
[391]392 Same as :c:func:`PyErr_NewException`, except that the new exception class can
393 easily be given a docstring: If *doc* is non-*NULL*, it will be used as the
394 docstring for the exception class.
395
396 .. versionadded:: 2.7
397
398
399.. c:function:: void PyErr_WriteUnraisable(PyObject *obj)
400
[2]401 This utility function prints a warning message to ``sys.stderr`` when an
402 exception has been set but it is impossible for the interpreter to actually
403 raise the exception. It is used, for example, when an exception occurs in an
404 :meth:`__del__` method.
405
406 The function is called with a single argument *obj* that identifies the context
407 in which the unraisable exception occurred. The repr of *obj* will be printed in
408 the warning message.
409
410
[391]411.. _unicodeexceptions:
412
413Unicode Exception Objects
414=========================
415
416The following functions are used to create and modify Unicode exceptions from C.
417
418.. c:function:: PyObject* PyUnicodeDecodeError_Create(const char *encoding, const char *object, Py_ssize_t length, Py_ssize_t start, Py_ssize_t end, const char *reason)
419
420 Create a :class:`UnicodeDecodeError` object with the attributes *encoding*,
421 *object*, *length*, *start*, *end* and *reason*.
422
423.. c:function:: PyObject* PyUnicodeEncodeError_Create(const char *encoding, const Py_UNICODE *object, Py_ssize_t length, Py_ssize_t start, Py_ssize_t end, const char *reason)
424
425 Create a :class:`UnicodeEncodeError` object with the attributes *encoding*,
426 *object*, *length*, *start*, *end* and *reason*.
427
428.. c:function:: PyObject* PyUnicodeTranslateError_Create(const Py_UNICODE *object, Py_ssize_t length, Py_ssize_t start, Py_ssize_t end, const char *reason)
429
430 Create a :class:`UnicodeTranslateError` object with the attributes *object*,
431 *length*, *start*, *end* and *reason*.
432
433.. c:function:: PyObject* PyUnicodeDecodeError_GetEncoding(PyObject *exc)
434 PyObject* PyUnicodeEncodeError_GetEncoding(PyObject *exc)
435
436 Return the *encoding* attribute of the given exception object.
437
438.. c:function:: PyObject* PyUnicodeDecodeError_GetObject(PyObject *exc)
439 PyObject* PyUnicodeEncodeError_GetObject(PyObject *exc)
440 PyObject* PyUnicodeTranslateError_GetObject(PyObject *exc)
441
442 Return the *object* attribute of the given exception object.
443
444.. c:function:: int PyUnicodeDecodeError_GetStart(PyObject *exc, Py_ssize_t *start)
445 int PyUnicodeEncodeError_GetStart(PyObject *exc, Py_ssize_t *start)
446 int PyUnicodeTranslateError_GetStart(PyObject *exc, Py_ssize_t *start)
447
448 Get the *start* attribute of the given exception object and place it into
449 *\*start*. *start* must not be *NULL*. Return ``0`` on success, ``-1`` on
450 failure.
451
452.. c:function:: int PyUnicodeDecodeError_SetStart(PyObject *exc, Py_ssize_t start)
453 int PyUnicodeEncodeError_SetStart(PyObject *exc, Py_ssize_t start)
454 int PyUnicodeTranslateError_SetStart(PyObject *exc, Py_ssize_t start)
455
456 Set the *start* attribute of the given exception object to *start*. Return
457 ``0`` on success, ``-1`` on failure.
458
459.. c:function:: int PyUnicodeDecodeError_GetEnd(PyObject *exc, Py_ssize_t *end)
460 int PyUnicodeEncodeError_GetEnd(PyObject *exc, Py_ssize_t *end)
461 int PyUnicodeTranslateError_GetEnd(PyObject *exc, Py_ssize_t *end)
462
463 Get the *end* attribute of the given exception object and place it into
464 *\*end*. *end* must not be *NULL*. Return ``0`` on success, ``-1`` on
465 failure.
466
467.. c:function:: int PyUnicodeDecodeError_SetEnd(PyObject *exc, Py_ssize_t end)
468 int PyUnicodeEncodeError_SetEnd(PyObject *exc, Py_ssize_t end)
469 int PyUnicodeTranslateError_SetEnd(PyObject *exc, Py_ssize_t end)
470
471 Set the *end* attribute of the given exception object to *end*. Return ``0``
472 on success, ``-1`` on failure.
473
474.. c:function:: PyObject* PyUnicodeDecodeError_GetReason(PyObject *exc)
475 PyObject* PyUnicodeEncodeError_GetReason(PyObject *exc)
476 PyObject* PyUnicodeTranslateError_GetReason(PyObject *exc)
477
478 Return the *reason* attribute of the given exception object.
479
480.. c:function:: int PyUnicodeDecodeError_SetReason(PyObject *exc, const char *reason)
481 int PyUnicodeEncodeError_SetReason(PyObject *exc, const char *reason)
482 int PyUnicodeTranslateError_SetReason(PyObject *exc, const char *reason)
483
484 Set the *reason* attribute of the given exception object to *reason*. Return
485 ``0`` on success, ``-1`` on failure.
486
487
488Recursion Control
489=================
490
491These two functions provide a way to perform safe recursive calls at the C
492level, both in the core and in extension modules. They are needed if the
493recursive code does not necessarily invoke Python code (which tracks its
494recursion depth automatically).
495
496.. c:function:: int Py_EnterRecursiveCall(char *where)
497
498 Marks a point where a recursive C-level call is about to be performed.
499
500 If :const:`USE_STACKCHECK` is defined, this function checks if the OS
501 stack overflowed using :c:func:`PyOS_CheckStack`. In this is the case, it
502 sets a :exc:`MemoryError` and returns a nonzero value.
503
504 The function then checks if the recursion limit is reached. If this is the
505 case, a :exc:`RuntimeError` is set and a nonzero value is returned.
506 Otherwise, zero is returned.
507
508 *where* should be a string such as ``" in instance check"`` to be
509 concatenated to the :exc:`RuntimeError` message caused by the recursion depth
510 limit.
511
512.. c:function:: void Py_LeaveRecursiveCall()
513
514 Ends a :c:func:`Py_EnterRecursiveCall`. Must be called once for each
515 *successful* invocation of :c:func:`Py_EnterRecursiveCall`.
516
517
[2]518.. _standardexceptions:
519
520Standard Exceptions
521===================
522
523All standard Python exceptions are available as global variables whose names are
524``PyExc_`` followed by the Python exception name. These have the type
[391]525:c:type:`PyObject\*`; they are all class objects. For completeness, here are all
[2]526the variables:
527
[391]528+-------------------------------------+----------------------------+----------+
529| C Name | Python Name | Notes |
530+=====================================+============================+==========+
531| :c:data:`PyExc_BaseException` | :exc:`BaseException` | (1), (4) |
532+-------------------------------------+----------------------------+----------+
533| :c:data:`PyExc_Exception` | :exc:`Exception` | \(1) |
534+-------------------------------------+----------------------------+----------+
535| :c:data:`PyExc_StandardError` | :exc:`StandardError` | \(1) |
536+-------------------------------------+----------------------------+----------+
537| :c:data:`PyExc_ArithmeticError` | :exc:`ArithmeticError` | \(1) |
538+-------------------------------------+----------------------------+----------+
539| :c:data:`PyExc_LookupError` | :exc:`LookupError` | \(1) |
540+-------------------------------------+----------------------------+----------+
541| :c:data:`PyExc_AssertionError` | :exc:`AssertionError` | |
542+-------------------------------------+----------------------------+----------+
543| :c:data:`PyExc_AttributeError` | :exc:`AttributeError` | |
544+-------------------------------------+----------------------------+----------+
545| :c:data:`PyExc_EOFError` | :exc:`EOFError` | |
546+-------------------------------------+----------------------------+----------+
547| :c:data:`PyExc_EnvironmentError` | :exc:`EnvironmentError` | \(1) |
548+-------------------------------------+----------------------------+----------+
549| :c:data:`PyExc_FloatingPointError` | :exc:`FloatingPointError` | |
550+-------------------------------------+----------------------------+----------+
551| :c:data:`PyExc_IOError` | :exc:`IOError` | |
552+-------------------------------------+----------------------------+----------+
553| :c:data:`PyExc_ImportError` | :exc:`ImportError` | |
554+-------------------------------------+----------------------------+----------+
555| :c:data:`PyExc_IndexError` | :exc:`IndexError` | |
556+-------------------------------------+----------------------------+----------+
557| :c:data:`PyExc_KeyError` | :exc:`KeyError` | |
558+-------------------------------------+----------------------------+----------+
559| :c:data:`PyExc_KeyboardInterrupt` | :exc:`KeyboardInterrupt` | |
560+-------------------------------------+----------------------------+----------+
561| :c:data:`PyExc_MemoryError` | :exc:`MemoryError` | |
562+-------------------------------------+----------------------------+----------+
563| :c:data:`PyExc_NameError` | :exc:`NameError` | |
564+-------------------------------------+----------------------------+----------+
565| :c:data:`PyExc_NotImplementedError` | :exc:`NotImplementedError` | |
566+-------------------------------------+----------------------------+----------+
567| :c:data:`PyExc_OSError` | :exc:`OSError` | |
568+-------------------------------------+----------------------------+----------+
569| :c:data:`PyExc_OverflowError` | :exc:`OverflowError` | |
570+-------------------------------------+----------------------------+----------+
571| :c:data:`PyExc_ReferenceError` | :exc:`ReferenceError` | \(2) |
572+-------------------------------------+----------------------------+----------+
573| :c:data:`PyExc_RuntimeError` | :exc:`RuntimeError` | |
574+-------------------------------------+----------------------------+----------+
575| :c:data:`PyExc_SyntaxError` | :exc:`SyntaxError` | |
576+-------------------------------------+----------------------------+----------+
577| :c:data:`PyExc_SystemError` | :exc:`SystemError` | |
578+-------------------------------------+----------------------------+----------+
579| :c:data:`PyExc_SystemExit` | :exc:`SystemExit` | |
580+-------------------------------------+----------------------------+----------+
581| :c:data:`PyExc_TypeError` | :exc:`TypeError` | |
582+-------------------------------------+----------------------------+----------+
583| :c:data:`PyExc_ValueError` | :exc:`ValueError` | |
584+-------------------------------------+----------------------------+----------+
585| :c:data:`PyExc_WindowsError` | :exc:`WindowsError` | \(3) |
586+-------------------------------------+----------------------------+----------+
587| :c:data:`PyExc_ZeroDivisionError` | :exc:`ZeroDivisionError` | |
588+-------------------------------------+----------------------------+----------+
[2]589
590.. index::
591 single: PyExc_BaseException
592 single: PyExc_Exception
593 single: PyExc_StandardError
594 single: PyExc_ArithmeticError
595 single: PyExc_LookupError
596 single: PyExc_AssertionError
597 single: PyExc_AttributeError
598 single: PyExc_EOFError
599 single: PyExc_EnvironmentError
600 single: PyExc_FloatingPointError
601 single: PyExc_IOError
602 single: PyExc_ImportError
603 single: PyExc_IndexError
604 single: PyExc_KeyError
605 single: PyExc_KeyboardInterrupt
606 single: PyExc_MemoryError
607 single: PyExc_NameError
608 single: PyExc_NotImplementedError
609 single: PyExc_OSError
610 single: PyExc_OverflowError
611 single: PyExc_ReferenceError
612 single: PyExc_RuntimeError
613 single: PyExc_SyntaxError
614 single: PyExc_SystemError
615 single: PyExc_SystemExit
616 single: PyExc_TypeError
617 single: PyExc_ValueError
618 single: PyExc_WindowsError
619 single: PyExc_ZeroDivisionError
620
621Notes:
622
623(1)
624 This is a base class for other standard exceptions.
625
626(2)
627 This is the same as :exc:`weakref.ReferenceError`.
628
629(3)
630 Only defined on Windows; protect code that uses this by testing that the
631 preprocessor macro ``MS_WINDOWS`` is defined.
632
633(4)
634 .. versionadded:: 2.5
635
636
[391]637String Exceptions
638=================
[2]639
[391]640.. versionchanged:: 2.6
641 All exceptions to be raised or caught must be derived from :exc:`BaseException`.
642 Trying to raise a string exception now raises :exc:`TypeError`.
[2]643
Note: See TracBrowser for help on using the repository browser.