Python Exceptions: Part Six

January 13, 2015 by Leave a Comment

exceptionsAs a special case for debugging purposes, Python includes the assert statement; it can be thought of as a conditional raise statement. A statement of the form:

	assert , <test> <data>

works like the following code:

	if __debug__:
		if not :
			raise AssertionError()

In other words, if the test evaluates to false, Python raises an exception: the data item is used as the exception’s constructor argument, if a data item is provided. Like all exceptions, the AssertionError exception will kill your program if it’s not caught with a try, in which case the data item shows up as part of the error message. Otherwsie, AssertionError exceptions can be caught and handled like any other exception.

As an added feature, assert statements may be removed from a compiled program’s byte code if the -0 Python command-line flag is used, thus optimizing the program (similar to assert statements in C/C++). AssertionError is a built-in exception, and the __debug__ flag is a built-in name that is automatically set to True unless the -0 flag is used. You can use a command line like python -0 code.py to run in optimized mode and disable asserts.

Assertions are typically used to verify program conditions during development. When displayed, their error message text automatically includes source code line information and the value listed in the assert statement.

As an example, consider a function to convert from Fahrenheit to Celsius. We’ll make it bail out if it sees a temperature less than absolute zero:

def FahrenheitToCelsius(ftemp):
	assert (ftemp >= -460), "Less than absolute zero!"
	return ((ftemp-32)*(5.0/9.0))

FahrenheitToCelsius(32)
FahrenheitToCelsius(55)
FahrenheitToCelsius(-500)

When the above code is executed, it produces the following result:

0.0
12.777777777777779
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in 
    FahrenheitToCelsius(-500)
  File "<pyshell#8>", line 2, in FahrenheitToCelsius
    assert (ftemp >= -460), "Less than absolute zero!"
AssertionError: Less than absolute zero!

It is important to keep in mind that assert is mostly intended for trapping user-defined constraints and not for catching actual programming errors. Because Python traps programming errors itself, there is usually no need to code asserts to catch things like out-of-bounds indexes, type mismatches, and zero divides. Such asserts are generally unnecessary. Because Python raises exceptions on errors automatically, you can let it do the job for you.

With/As Clauses

Python 2.6 and above introduced a new exception-related statement: the with, and its optional as clause. This statement is designed to work with context manager objects, which support a new method-based protocol. The with/as statement is designed to be an alternative to common try/finally statements. Like try/finally, with/as is intended for specifying termination-time or cleanup activity that must run regardless of whether an exception occurs in a processing step. Unlike try/finally, the with statement supports a richer object-based protocol for specifying both entry and exit actions around a block of code.

The basic format of the with statement looks like this:

	with expression [as variable]:
		with-block

The expression here is assumed to return an object that supports the context management protocol. This object may also return a value that will be assigned to the name variable if the optional as clause is present.

Note that the variable is not necessarily assigned the result of the expression. The result of the expression is the object that supports the context protocol, and the variable may be assigned something else intended to be used inside the statement. The object returned by the expression may then run startup code before the with-block is started, as well as termination code after the block is done, regardless of whether the block raised an exception or not.

Some built-in Python objects have been augmented to support the context management protocol, and so can be used with the with statement. For example, file objects have a context manager that automatically closes the file after the with block regardless of whether an exception is raised:

	with open(r'file.txt') as myfile:
		for line in myfile:
			print(line)

Here, the call to open returns a simple file object that is assigned to the name myfile. We can use myfile with the usual file tools. In this case, the file iterator reads line by line in the for loop.

But this object also supports the context management protocol used by the with statement. After this with statement has run, the context management machinery guarantees that the file object referenced by myfile is automatically closed, even if the for loop raised an exception while processing the file.

Although file objects are automatically closed on garbage collection, it is not always easy to know when that will occur. The with statement in this role is an alternative that allows us to be sure that the close will occur after execution of a specific block of code. We can accomplish a similar effect with the more general and explicit try/finally statement, but it requires four lines of code instead of one:

	myfile = open(r'file.txt')
	try:
		for line in myfile:
			print(line)
	finally:
		myfile.close()

The lock and condition synchronization objects they define may also be used with the with statement, because they support the context management protocol:

	lock = threading.lock()
	with lock:
	# critical code
	...access shared resources here...

Here, the context management machinery guarantees that the lock is automatically acquired before the block is executed and released on the block is complete, regardless of exception outcomes.

External Links:

Assertions in Python at www.tutorialspoint.com

Filed Under: Guides, Tutorials Tagged With: , , , ,

Python Exceptions: Part Five

January 9, 2015 by Leave a Comment

exceptions

The Raise Statement

One of the statements not yet covered in this series on exceptions is the raise statement. To trigger excepts explicitly in Python, you can code raise statements. Their general form is simple – a raise statement consists of the word raise, optionally followed by the class to be raised or an instance of it:

	raise  # Raise an instance of a class
	raise  # Make and raise instance of a class
	raise  # Re-raise the most recent exception

The first raise form presented here is the most common one. We provide an instance directly, either created before the raise or within the raise statement itself. If we pass a class instead, then Python will call the class with no constructor arguments to create an instance to be raised. This form is equivalent to adding parenthesis after the class reference. The last form re-raises the most recently raised exception. It is commonly used in exception handlers to propagate exceptions that have been caught.

With built-in exceptions, the following two forms are equivalent:

	raise IndexError
	raise IndexError()

Both examples raise an instance of the exception class named, although the first creates the instance implicitly. We can also create the instance ahead of time, because the raise statement accepts any kind of object reference:

	my_exc = IndexError()
	raise my_exc

	my_excs = [IndexError, TypeError]
	raise my_excs[0]

When an exception is raised, Python sends the raised instance along with the exception. If a try includes an except name as X: clause, the variable X will be assigned the instance provided in the raise:

	try:
		...
	except IndexError as X: 
		...

The as is optional in the try handler. If it is omitted, the instance is simply not assigned to to a name. Including it allows the handler to access both data in the instance and methods in the exception class.

This model works the same for user-defined exceptions coded in classes:

	class MyExc(Exception): pass
	...
	raise MyExc('wooble')
	...
	try:
		...
	except MyExc as X:
		print(X.args)

Regardless of how exceptions are named, they are always identified by instance objects, and at most one is active at any given time. Once caught by an except clause anywhere in the program, an exception dies unless it is re-raised by another raise statement or error.

A raise statement that does not include an exception name or extra data value simply re-raises the current exception. This form is typically used if you need to catch and handle an exception, but you don’t want the exception to die in your code. Running a raise this way re-raises the exception and propagates it to a higher handler.

Finally, Python (3.0 and above) also allows an optional from clause:

	raise exception from otherexception

When the from is used, the second expression specifies another exception class or instance to attach to the raised exception’s __cause__ atrribute. If the raised exception is not caught, Python prints both exceptions as part of the standard error message:

>>> try:
... 	1/0
...	except Exception as E:
...	raise TypeError('Not good') from E

When an exception is raised inside an exception handler, a similar procedure is followed implicitly. The previous exception is attached to the new exception’s __context__ attribute and is again displayed in the standard error message if the exception goes uncaught.

External Links:

Handling Exceptions at Python Wiki Built-in Exceptions at docs.python.org

Filed Under: General, Tutorials Tagged With: , , , , ,

Python Exceptions: Part Four

January 5, 2015 by Leave a Comment

exceptionsPython Exceptions: try/except/finally

In all versions of Python prior to Release 2.5, there were two types of try statements. You could either use a finally to ensure that cleanup code was always run, or write except blocks to catch and recover from specific exceptions and optionally specify an else clause to be run if no exceptions occurred. In other words, the finally clause could not by mixed with except and else.

That has changed with Python 2.5 and later. Now, the two statements have merged; we can mix finally except and else clauses in the same statement:

try:
	statements
except Exception1:
	handler1
except Exception2:
	handler2
else:
	else_block

The code in this statement’s main-action block is executed first, as usual. If that code raises an exception, all the except blocks are tested, one after another, looking for a match to the exception raised. If the exception raised is Exception1, the handler1 block is executed; if it’s Exception2, handler2 is run, etc. If no exception is raised, the else-block is executed.

No matter what’s happened previously, the finally-block is executed once the main action block is complete and any raised exceptions have been handled. In fact, the code in the finally-block will be run even if there is an error in an exception handler or the else-block and a new exception is raised.

As always, the finally clause does not end the exception. If an exception is active when the finally-block is executed, it continues to be propagated after the finally-block runs, and control jumps somewhere else in the program. If no exception is active when the finally is run, control resumes after the entire try statement.

The effect here is that the finally-block is always run, regardless of whether [1] an exception occurred in the main action and was handled; [2] an exception occurred in the main action and was not handled; no exceptions occurred in the main action, and/or [4] a new exception was triggered in one of the handlers. Again, the finally serves to specify cleanup actions that must always occur on the way out of the try, regardless of what exceptions have been raised or handled.

When try, except, else and finally are combined like this, the order must be like this:

	try -> except -> else -> finally

where the else and finally are optional, and there may be zero or more except blocks, but there must be at least one except if an else appears. The try statement essentially consists of two parts: excepts with an optional else, and/or the finally.

Because of these rules, the else can appear only if there is at least one except, and it is always possible to mix except and finally, regardless of whether an else appears to though the except can omit an exception name to catch everything and run a raise statement to re-raise the current exception. If you violate any of these rules, Python will raise a syntax error exception before your code runs.

Finally, prior to Python 2.5, it is actually possible to combine finally and except clauses in a try by syntactically nesting a try/except in the try block of a try/finally statement. The following has the same effect as the new merged form:

try:
	try:
		main-action
	except Exception1:
		handler1
	except Exception2:
		handler2
	...
	else
		no-error
	finally:
		cleanup

Again, the finally block is always run on the way out, regardless of what happened in the main action and regardless of any exception handlers run in the nested try. Since an else always requires an except, this nested form even sports the same mixing constraints of the unified statement form outlined in the preceding section. But this nested equivalent is more obscure and requires more code than the new merged form. Mixing finally into the same statement makes your code easier to write and read and is thus the generally preferred technique.

External Links:

Handling Exceptions at Python Wiki Built-in Exceptions at docs.python.org

Filed Under: Guides, Tutorials Tagged With: , , , , , ,

Python Exceptions: Part One

December 22, 2014 by Leave a Comment

exceptionsExceptions are events that can modify the flow of control through a program; they are triggered automatically on errors, and can be triggered and intercepted by your Python code. Python has the following statements to deal with exceptions:

  • try/except: Catch and recover from exceptions raised by Python (or by you)
  • try/finally: Perform cleanup actions, whether exceptions occur or not.
  • raise: Trigger an exception manually in your code.
  • assert: Conditionally trigger an exception in your code.
  • with/as: Implement context managers in Python 2.6/3.0.

Exceptions let us jump out of large chunks of a program (whatever is included in the “try” block). The try statement works as follows:

  • First, the try clause is executed.
  • If no exception occurs, the except clause is skipped and execution of the try statement is finished.

To provide an example, let’s assume we have a character string:

>>> myStr = ‘Hello, world!’
>>> print(myStr[3])
l

If we reference an index within the bounds of the string, then the code works as it should, and we get no error. But if we specify an index outside of the bounds of the string, we get a different result:

Traceback (most recent call last):
File “<pyshell#3>”, line 1, in
print(myStr[13])
IndexError: string index out of range

Handling Exceptions

In our programs, we can let an error occur, in which case the program stops running, or we can try to handle it. The error generated by trying to access myStr[13] was an IndexError, so we will handle the IndexError exception in our code:

def testException():
	myStr = 'Hello, world!'
	try:
		print(myStr[13])
		print('No errors so far.')
	except IndexError:
		print('Index error.')
	print('Continuing...')

In this code, we have a try/except block. In try, we attempt to print out myStr[13]. If there is no error, we will move on to the next line (and print out ‘No errors no far.’). If an IndexError exception is raised, we will jump immediately to the except statement. The last line (print out ‘Continuing…’) will execute whether or not an exception was raised. Not surprisingly, we get the following output when we run the function:

>>> testException()
Index error.
Continuing…

Note that if the program generated an exception that was not an IndexError, the exception would be unhandled and the program would terminate with an error. However, a try statement may have more than one except clause, to specify handlers for different exceptions. At most one handler will be executed. Handlers only handle exceptions that occur in the corresponding try clause, not in other handlers of the same try statement. An except clause may also name multiple exceptions as a parenthesized tuple. For example:

except (IndexError, ValueError, RuntimeError):
pass

In this case, the last except clause may omit the exception name or names to serve as a wildcard. You can use this to print an error message and re-raise the exception to allow the caller to handle the exception as well. For example, we could rewrite the above function:

def testException():
    myStr = 'Hello, world!'
    try:
        print(myStr[12])
        print('No errors so far.')
        a = int(myStr[12])
    except IndexError:
        print('Index error.')
    except ValueError:
        print('Value error.')
    print('Continuing...')

If we execute this function, we get the following result:

>>> testException()
!
No errors so far.
Value error.
Continuing…

The first print() call in the try block will not raise an exception, but trying to convert myStr[12] to an integer will generate a ValueError exception.

You can also add a finally block to your code. The finally block is inserted after the try block and is executed whether or not an exception is generated (and whether or not said exception is handled). For example, we might have the following function:

def testException():
    myStr = 'Hello, world!'
    try:
        print(myStr[12])
        print('No errors so far.')
        b.append(myStr[12])
    except IndexError:
        print('Index error.')
    except ValueError:
        print('Value error.')
    finally:
        print('Finally block reached.')
    print('Continuing...')

Here, the line with the b.append() call will generate an unhandled exception because b was not previously defined as a list. Thus, it will not reach the last line of the program, but it will execute what is in the finally block:

!
No errors so far.
Finally block reached.
Traceback (most recent call last):
File “N:\Users\David\workspace\exception\exception.py”, line 16, in
testException()
File “N:\Users\David\workspace\exception\exception.py”, line 7, in testException
b.append(myStr[12])
NameError: global name ‘b’ is not defined

Exception handling in Python is not unlike try/catch blocks in C++ and try/catch/finally blocks in Java. It provides a useful alternative to the old C approach, which was to propagate error codes:

int functionCall()
{
	if (doSomething() == ERROR_CODE)
		return ERROR_CODE;
}

void main()
{
	if (functionCall() == ERROR_CODE)
		badResult();
	else
		goodResult();
}

In this case, a lot of our code is devoted to error handling. If we had a try/except block, however, we could just wrap the code we think might cause an error in a try block.

We are not quite done examining exception handling in Python, but hopefully this will serve as a good introduction.

External Links:

Handling Exceptions at Python Wiki

Built-in Exceptions at docs.python.org

Filed Under: Guides, Tutorials Tagged With: , , , ,