Specify that the 'message' argument should be a string that is human-readable.
This commit is contained in:
parent
f212309353
commit
7ac5fe3be0
15
pep-0352.txt
15
pep-0352.txt
|
@ -86,13 +86,16 @@ work in Python 2.x is covered in the `Transition Plan`_ section)::
|
|||
The ``message`` attribute will contain either the first argument
|
||||
passed in at instantiation of the object or the empty string if no
|
||||
arguments were passed in. The attribute is meant to act as a common
|
||||
location to store any extra information that is to be passed along
|
||||
with the exception that goes beyond the location of the exception
|
||||
within the exception hierarchy and the exception's type.
|
||||
location to store any message that is to be passed along
|
||||
with the exception that goes beyond the location of where the exception
|
||||
occurred and the exception's type.
|
||||
|
||||
No restriction is placed upon what may be passed in for ``message``.
|
||||
This provides backwards-compatibility with how the arguments passed
|
||||
into Exception have no restrictions.
|
||||
No restriction is placed upon what may be passed in for ``message``
|
||||
for backwards-compatibility reasons. In practice, though, only
|
||||
strings should be used. This keeps the string representation of the
|
||||
exception to be a useful message about the exception that is
|
||||
human-readable. Including programmatic information (e.g., an error
|
||||
code number) should be stored as a separate attribute in a subclass.
|
||||
|
||||
The ``args`` attribute is deprecated. While allowing multiple
|
||||
arguments to be passed can be helpful, it is in no way essential. It
|
||||
|
|
Loading…
Reference in New Issue