8.1.Syntax Errors¶

Syntax errors, also known as parsing errors, are perhaps the most common kind ofcomplaint you get while you are still learning Python:

>>>whileTrueprint('Hello world')  File"<stdin>", line1whileTrueprint('Hello world')^^^^^SyntaxError:invalid syntax

The parser repeats the offending line and displays little arrows pointingat the place where the error was detected. Note that this is not always theplace that needs to be fixed. In the example, the error is detected at thefunctionprint(), since a colon (':') is missing just before it.

The file name (<stdin> in our example) and line number are printed so youknow where to look in case the input came from a file.

8.2.Exceptions¶

Even if a statement or expression is syntactically correct, it may cause anerror when an attempt is made to execute it. Errors detected during executionare calledexceptions and are not unconditionally fatal: you will soon learnhow to handle them in Python programs. Most exceptions are not handled byprograms, however, and result in error messages as shown here:

>>>10*(1/0)Traceback (most recent call last):  File"<stdin>", line1, in<module>10*(1/0)~^~ZeroDivisionError:division by zero>>>4+spam*3Traceback (most recent call last):  File"<stdin>", line1, in<module>4+spam*3^^^^NameError:name 'spam' is not defined>>>'2'+2Traceback (most recent call last):  File"<stdin>", line1, in<module>'2'+2~~~~^~~TypeError:can only concatenate str (not "int") to str

The last line of the error message indicates what happened. Exceptions come indifferent types, and the type is printed as part of the message: the types inthe example areZeroDivisionError,NameError andTypeError.The string printed as the exception type is the name of the built-in exceptionthat occurred. This is true for all built-in exceptions, but need not be truefor user-defined exceptions (although it is a useful convention). Standardexception names are built-in identifiers (not reserved keywords).

The rest of the line provides detail based on the type of exception and whatcaused it.

The preceding part of the error message shows the context where the exceptionoccurred, in the form of a stack traceback. In general it contains a stacktraceback listing source lines; however, it will not display lines read fromstandard input.

Built-in Exceptions lists the built-in exceptions and their meanings.

8.3.Handling Exceptions¶

It is possible to write programs that handle selected exceptions. Look at thefollowing example, which asks the user for input until a valid integer has beenentered, but allows the user to interrupt the program (usingControl-C orwhatever the operating system supports); note that a user-generated interruptionis signalled by raising theKeyboardInterrupt exception.

>>>whileTrue:...try:...x=int(input("Please enter a number: "))...break...exceptValueError:...print("Oops!  That was no valid number.  Try again...")...

Thetry statement works as follows.

• First, thetry clause (the statement(s) between thetry andexcept keywords) is executed.

• If no exception occurs, theexcept clause is skipped and execution of thetry statement is finished.

• If an exception occurs during execution of thetry clause, the rest of theclause is skipped. Then, if its type matches the exception named after theexcept keyword, theexcept clause is executed, and then executioncontinues after the try/except block.

• If an exception occurs which does not match the exception named in theexceptclause, it is passed on to outertry statements; if no handler isfound, it is anunhandled exception and execution stops with an error message.

Atry statement may have more than oneexcept clause, to specifyhandlers for different exceptions. At most one handler will be executed.Handlers only handle exceptions that occur in the correspondingtry clause,not in other handlers of the sametry statement. Anexcept clausemay name multiple exceptions as a parenthesized tuple, for example:

...except(RuntimeError,TypeError,NameError):...pass

A class in anexcept clause matches exceptions which are instances of theclass itself or one of its derived classes (but not the other way around — anexcept clause listing a derived class does not match instances of its base classes).For example, the following code will print B, C, D in that order:

classB(Exception):passclassC(B):passclassD(C):passforclsin[B,C,D]:try:raisecls()exceptD:print("D")exceptC:print("C")exceptB:print("B")

Note that if theexcept clauses were reversed (withexceptB first), itwould have printed B, B, B — the first matchingexcept clause is triggered.

When an exception occurs, it may have associated values, also known as theexception’sarguments. The presence and types of the arguments depend on theexception type.

Theexcept clause may specify a variable after the exception name. Thevariable is bound to the exception instance which typically has anargsattribute that stores the arguments. For convenience, builtin exceptiontypes define__str__() to print all the arguments without explicitlyaccessing.args.

>>>try:...raiseException('spam','eggs')...exceptExceptionasinst:...print(type(inst))# the exception type...print(inst.args)# arguments stored in .args...print(inst)# __str__ allows args to be printed directly,...# but may be overridden in exception subclasses...x,y=inst.args# unpack args...print('x =',x)...print('y =',y)...<class 'Exception'>('spam', 'eggs')('spam', 'eggs')x = spamy = eggs

The exception’s__str__() output is printed as the last part (‘detail’)of the message for unhandled exceptions.

BaseException is the common base class of all exceptions. One of itssubclasses,Exception, is the base class of all the non-fatal exceptions.Exceptions which are not subclasses ofException are not typicallyhandled, because they are used to indicate that the program should terminate.They includeSystemExit which is raised bysys.exit() andKeyboardInterrupt which is raised when a user wishes to interruptthe program.

Exception can be used as a wildcard that catches (almost) everything.However, it is good practice to be as specific as possible with the typesof exceptions that we intend to handle, and to allow any unexpectedexceptions to propagate on.

The most common pattern for handlingException is to print or logthe exception and then re-raise it (allowing a caller to handle theexception as well):

importsystry:f=open('myfile.txt')s=f.readline()i=int(s.strip())exceptOSErroraserr:print("OS error:",err)exceptValueError:print("Could not convert data to an integer.")exceptExceptionaserr:print(f"Unexpected{err=},{type(err)=}")raise

Thetry …except statement has an optionalelseclause, which, when present, must follow allexcept clauses. It is usefulfor code that must be executed if thetry clause does not raise an exception.For example:

forarginsys.argv[1:]:try:f=open(arg,'r')exceptOSError:print('cannot open',arg)else:print(arg,'has',len(f.readlines()),'lines')f.close()

The use of theelse clause is better than adding additional code tothetry clause because it avoids accidentally catching an exceptionthat wasn’t raised by the code being protected by thetry …except statement.

Exception handlers do not handle only exceptions that occur immediately in thetry clause, but also those that occur inside functions that are called (evenindirectly) in thetry clause. For example:

>>>defthis_fails():...x=1/0...>>>try:...this_fails()...exceptZeroDivisionErroraserr:...print('Handling run-time error:',err)...Handling run-time error: division by zero

8.4.Raising Exceptions¶

Theraise statement allows the programmer to force a specifiedexception to occur. For example:

>>>raiseNameError('HiThere')Traceback (most recent call last):  File"<stdin>", line1, in<module>raiseNameError('HiThere')NameError:HiThere

The sole argument toraise indicates the exception to be raised.This must be either an exception instance or an exception class (a class thatderives fromBaseException, such asException or one of itssubclasses). If an exception class is passed, it will be implicitlyinstantiated by calling its constructor with no arguments:

raiseValueError# shorthand for 'raise ValueError()'

If you need to determine whether an exception was raised but don’t intend tohandle it, a simpler form of theraise statement allows you tore-raise the exception:

>>>try:...raiseNameError('HiThere')...exceptNameError:...print('An exception flew by!')...raise...An exception flew by!Traceback (most recent call last):  File"<stdin>", line2, in<module>raiseNameError('HiThere')NameError:HiThere

8.5.Exception Chaining¶

If an unhandled exception occurs inside anexcept section, it willhave the exception being handled attached to it and included in the errormessage:

>>>try:...open("database.sqlite")...exceptOSError:...raiseRuntimeError("unable to handle error")...Traceback (most recent call last):  File"<stdin>", line2, in<module>open("database.sqlite")~~~~^^^^^^^^^^^^^^^^^^^FileNotFoundError:[Errno 2] No such file or directory: 'database.sqlite'During handling of the above exception, another exception occurred:Traceback (most recent call last):  File"<stdin>", line4, in<module>raiseRuntimeError("unable to handle error")RuntimeError:unable to handle error

To indicate that an exception is a direct consequence of another, theraise statement allows an optionalfrom clause:

# exc must be exception instance or None.raiseRuntimeErrorfromexc

This can be useful when you are transforming exceptions. For example:

>>>deffunc():...raiseConnectionError...>>>try:...func()...exceptConnectionErrorasexc:...raiseRuntimeError('Failed to open database')fromexc...Traceback (most recent call last):  File"<stdin>", line2, in<module>func()~~~~^^  File"<stdin>", line2, infuncConnectionErrorThe above exception was the direct cause of the following exception:Traceback (most recent call last):  File"<stdin>", line4, in<module>raiseRuntimeError('Failed to open database')fromexcRuntimeError:Failed to open database

It also allows disabling automatic exception chaining using thefromNoneidiom:

>>>try:...open('database.sqlite')...exceptOSError:...raiseRuntimeErrorfromNone...Traceback (most recent call last):  File"<stdin>", line4, in<module>raiseRuntimeErrorfromNoneRuntimeError

For more information about chaining mechanics, seeBuilt-in Exceptions.

8.6.User-defined Exceptions¶

Programs may name their own exceptions by creating a new exception class (seeClasses for more about Python classes). Exceptions should typicallybe derived from theException class, either directly or indirectly.

Exception classes can be defined which do anything any other class can do, butare usually kept simple, often only offering a number of attributes that allowinformation about the error to be extracted by handlers for the exception.

Most exceptions are defined with names that end in “Error”, similar to thenaming of the standard exceptions.

Many standard modules define their own exceptions to report errors that mayoccur in functions they define.

8.7.Defining Clean-up Actions¶

Thetry statement has another optional clause which is intended todefine clean-up actions that must be executed under all circumstances. Forexample:

>>>try:...raiseKeyboardInterrupt...finally:...print('Goodbye, world!')...Goodbye, world!Traceback (most recent call last):  File"<stdin>", line2, in<module>raiseKeyboardInterruptKeyboardInterrupt

If afinally clause is present, thefinallyclause will execute as the last task before thetrystatement completes. Thefinally clause runs whether ornot thetry statement produces an exception. The followingpoints discuss more complex cases when an exception occurs:

• If an exception occurs during execution of thetryclause, the exception may be handled by anexceptclause. If the exception is not handled by anexceptclause, the exception is re-raised after thefinallyclause has been executed.

• An exception could occur during execution of anexceptorelse clause. Again, the exception is re-raised afterthefinally clause has been executed.

• If thefinally clause executes abreak,continue orreturn statement, exceptions are notre-raised.

• If thetry statement reaches abreak,continue orreturn statement, thefinally clause will execute just prior to thebreak,continue orreturnstatement’s execution.

• If afinally clause includes areturnstatement, the returned value will be the one from thefinally clause’sreturn statement, not thevalue from thetry clause’sreturnstatement.

For example:

>>>defbool_return():...try:...returnTrue...finally:...returnFalse...>>>bool_return()False

A more complicated example:

>>>defdivide(x,y):...try:...result=x/y...exceptZeroDivisionError:...print("division by zero!")...else:...print("result is",result)...finally:...print("executing finally clause")...>>>divide(2,1)result is 2.0executing finally clause>>>divide(2,0)division by zero!executing finally clause>>>divide("2","1")executing finally clauseTraceback (most recent call last):  File"<stdin>", line1, in<module>divide("2","1")~~~~~~^^^^^^^^^^  File"<stdin>", line3, individeresult=x/y~~^~~TypeError:unsupported operand type(s) for /: 'str' and 'str'

As you can see, thefinally clause is executed in any event. TheTypeError raised by dividing two strings is not handled by theexcept clause and therefore re-raised after thefinallyclause has been executed.

In real world applications, thefinally clause is useful forreleasing external resources (such as files or network connections), regardlessof whether the use of the resource was successful.

8.8.Predefined Clean-up Actions¶

Some objects define standard clean-up actions to be undertaken when the objectis no longer needed, regardless of whether or not the operation using the objectsucceeded or failed. Look at the following example, which tries to open a fileand print its contents to the screen.

forlineinopen("myfile.txt"):print(line,end="")

The problem with this code is that it leaves the file open for an indeterminateamount of time after this part of the code has finished executing.This is not an issue in simple scripts, but can be a problem for largerapplications. Thewith statement allows objects like files to beused in a way that ensures they are always cleaned up promptly and correctly.

withopen("myfile.txt")asf:forlineinf:print(line,end="")

After the statement is executed, the filef is always closed, even if aproblem was encountered while processing the lines. Objects which, like files,provide predefined clean-up actions will indicate this in their documentation.

8.9.Raising and Handling Multiple Unrelated Exceptions¶

There are situations where it is necessary to report several exceptions thathave occurred. This is often the case in concurrency frameworks, when severaltasks may have failed in parallel, but there are also other use cases whereit is desirable to continue execution and collect multiple errors rather thanraise the first exception.

The builtinExceptionGroup wraps a list of exception instances sothat they can be raised together. It is an exception itself, so it can becaught like any other exception.

>>>deff():...excs=[OSError('error 1'),SystemError('error 2')]...raiseExceptionGroup('there were problems',excs)...>>>f()  + Exception Group Traceback (most recent call last):  |   File "<stdin>", line 1, in <module>  |     f()  |     ~^^  |   File "<stdin>", line 3, in f  |     raise ExceptionGroup('there were problems', excs)  | ExceptionGroup: there were problems (2 sub-exceptions)  +-+---------------- 1 ----------------    | OSError: error 1    +---------------- 2 ----------------    | SystemError: error 2    +------------------------------------>>>try:...f()...exceptExceptionase:...print(f'caught{type(e)}: e')...caught <class 'ExceptionGroup'>: e>>>

By usingexcept* instead ofexcept, we can selectivelyhandle only the exceptions in the group that match a certaintype. In the following example, which shows a nested exceptiongroup, eachexcept* clause extracts from the group exceptionsof a certain type while letting all other exceptions propagate toother clauses and eventually to be reraised.

>>>deff():...raiseExceptionGroup(..."group1",...[...OSError(1),...SystemError(2),...ExceptionGroup(..."group2",...[...OSError(3),...RecursionError(4)...]...)...]...)...>>>try:...f()...except*OSErrorase:...print("There were OSErrors")...except*SystemErrorase:...print("There were SystemErrors")...There were OSErrorsThere were SystemErrors  + Exception Group Traceback (most recent call last):  |   File "<stdin>", line 2, in <module>  |     f()  |     ~^^  |   File "<stdin>", line 2, in f  |     raise ExceptionGroup(  |     ...<12 lines>...  |     )  | ExceptionGroup: group1 (1 sub-exception)  +-+---------------- 1 ----------------    | ExceptionGroup: group2 (1 sub-exception)    +-+---------------- 1 ----------------      | RecursionError: 4      +------------------------------------>>>

Note that the exceptions nested in an exception group must be instances,not types. This is because in practice the exceptions would typicallybe ones that have already been raised and caught by the program, alongthe following pattern:

>>>excs=[]...fortestintests:...try:...test.run()...exceptExceptionase:...excs.append(e)...>>>ifexcs:...raiseExceptionGroup("Test Failures",excs)...

8.10.Enriching Exceptions with Notes¶

When an exception is created in order to be raised, it is usually initializedwith information that describes the error that has occurred. There are caseswhere it is useful to add information after the exception was caught. For thispurpose, exceptions have a methodadd_note(note) that accepts a string andadds it to the exception’s notes list. The standard traceback renderingincludes all notes, in the order they were added, after the exception.

>>>try:...raiseTypeError('bad type')...exceptExceptionase:...e.add_note('Add some information')...e.add_note('Add some more information')...raise...Traceback (most recent call last):  File"<stdin>", line2, in<module>raiseTypeError('bad type')TypeError:bad typeAdd some informationAdd some more information>>>

For example, when collecting exceptions into an exception group, we may wantto add context information for the individual errors. In the following eachexception in the group has a note indicating when this error has occurred.

>>>deff():...raiseOSError('operation failed')...>>>excs=[]>>>foriinrange(3):...try:...f()...exceptExceptionase:...e.add_note(f'Happened in Iteration{i+1}')...excs.append(e)...>>>raiseExceptionGroup('We have some problems',excs)  + Exception Group Traceback (most recent call last):  |   File "<stdin>", line 1, in <module>  |     raise ExceptionGroup('We have some problems', excs)  | ExceptionGroup: We have some problems (3 sub-exceptions)  +-+---------------- 1 ----------------    | Traceback (most recent call last):    |   File "<stdin>", line 3, in <module>    |     f()    |     ~^^    |   File "<stdin>", line 2, in f    |     raise OSError('operation failed')    | OSError: operation failed    | Happened in Iteration 1    +---------------- 2 ----------------    | Traceback (most recent call last):    |   File "<stdin>", line 3, in <module>    |     f()    |     ~^^    |   File "<stdin>", line 2, in f    |     raise OSError('operation failed')    | OSError: operation failed    | Happened in Iteration 2    +---------------- 3 ----------------    | Traceback (most recent call last):    |   File "<stdin>", line 3, in <module>    |     f()    |     ~^^    |   File "<stdin>", line 2, in f    |     raise OSError('operation failed')    | OSError: operation failed    | Happened in Iteration 3    +------------------------------------>>>