String Exceptions

It is assumed that removing string exceptions will be uncontroversial, since it has been intended since at least Python 1.5, when the standard exception types were changed to classes [1].

For the record: string exceptions should be removed because the presence of two kinds of exception complicates the language without any compensation. Instance exceptions are superior because, for example,

• the class-instance relationship more naturally expresses the relationship between the exception type and value,
• they can be organized naturally using superclass-subclass relationships, and
• they can encapsulate error-reporting behaviour (for example).

Implicit Instantiation

Guido’s 1997 essay [1] on changing the standard exceptions into classes makes clear why raise can instantiate implicitly:

“The raise statement has been extended to allow raising a class exception without explicit instantiation. The following forms, called the “compatibility forms” of the raise statement […] The motivation for introducing the compatibility forms was to allow backward compatibility with old code that raised a standard exception.”

For example, it was desired that pre-1.5 code which used string exception syntax such as

raise TypeError, 'not an int'

would work both on versions of Python in which TypeError was a string, and on versions in which it was a class.

When no such consideration obtains – that is, when the desired exception type is not a string in any version of the software which the code must support – there is no good reason to instantiate implicitly, and it is clearer not to. For example:

1. In the code

   try:
       raise MyError, raised
   except MyError, caught:
       pass
   

   the syntactic parallel between the raise and except statements strongly suggests that raised and caught refer to the same object. For string exceptions this actually is the case, but for instance exceptions it is not.

2. When instantiation is implicit, it is not obvious when it occurs, for example, whether it occurs when the exception is raised or when it is caught. Since it actually happens at the raise, the code should say so.

   (Note that at the level of the C API, an exception can be “raised” and “caught” without being instantiated; this is used as an optimization by, for example, PyIter_Next. But in Python, no such optimization is or should be available.)

3. An implicitly instantiating raise statement with no arguments, such as

   raise MyError
   

   simply does not do what it says: it does not raise the named object.

4. The equivalence of

   raise MyError
   raise MyError()
   

   conflates classes and instances, creating a possible source of confusion for beginners. (Moreover, it is not clear that the interpreter could distinguish between a new-style class and an instance of such a class, so implicit instantiation may be an obstacle to any future plan to let exceptions be new-style objects.)

In short, implicit instantiation has no advantages other than backwards compatibility, and so should be phased out along with what it exists to ensure compatibility with, namely, string exceptions.

Migration Plan

from __future__ import raise_with_two_args

raising strings will be impossible in the future

raising classes will be impossible in the future

raising with three arguments will be impossible in the future

Examples

class MyError(Exception):
    pass

raise MyError, 'spam'

raise MyError('spam')

MyError = 'spam'
raise MyError, 'eggs'

class MyError(Exception):
    pass

raise MyError('eggs')

raise MyError, 'spam', mytraceback

raise MyError('spam'), mytraceback

from __future__ import raise_with_two_args

raise sys.exc_type, sys.exc_info, sys.exc_traceback

raise

New-Style Exceptions

Implicit instantiation might conflict with future plans to allow instances of new-style classes to be used as exceptions. In order to decide whether to instantiate implicitly, the raise machinery must determine whether the first argument is a class or an instance – but with new-style classes there is no clear and strong distinction.

Under this proposal, the problem would be avoided because the exception would already have been instantiated. However, there are two plausible alternative solutions:

1. Require exception types to be subclasses of Exception, and instantiate implicitly if and only if

   issubclass(firstarg, Exception)
   

2. Instantiate implicitly if and only if

   isinstance(firstarg, type)
   

Thus eliminating implicit instantiation entirely is not necessary to solve this problem.

Ugliness of Explicit Instantiation

Some respondents felt that the explicitly instantiating syntax is uglier, especially in cases when no arguments are supplied to the exception constructor:

raise TypeError()

The problem is particularly acute when the exception instance itself is not of interest, that is, when the only relevant point is the exception type:

try:
    # ... deeply nested search loop ...
        raise Found
except Found:
    # ...

In such cases the symmetry between raise and except can be more expressive of the intent of the code.

Guido opined that the implicitly instantiating syntax is “a tad prettier” even for cases with a single argument, since it has less punctuation.

Performance Penalty of Warnings

Experience with deprecating apply() shows that use of the warning framework can incur a significant performance penalty.

Code which instantiates explicitly would not be affected, since the run-time checks necessary to determine whether to issue a warning are exactly those which are needed to determine whether to instantiate implicitly in the first place. That is, such statements are already incurring the cost of these checks.

Code which instantiates implicitly would incur a large cost: timing trials indicate that issuing a warning (whether it is suppressed or not) takes about five times more time than simply instantiating, raising, and catching an exception.

This penalty is mitigated by the fact that raise statements are rarely on performance-critical execution paths.

Traceback Argument

As the proposal stands, it would be impossible to use the traceback argument to raise conveniently with all 2.x versions of Python.

For compatibility with versions < 2.4, the three-argument form must be used; but this form would produce warnings with versions >= 2.4. Those warnings could be suppressed, but doing so is awkward because the relevant type of warning is issued at compile-time.

If this PEP were still under consideration, this objection would be met by extending the phase-in period. For example, warnings could first be issued in 3.0, and become errors in some later release.