Author Dusty Phillips Reviewers

[
 102 
]
When we call this function, we see that the first 
print
statement executes, as well
as the first line in the 
no_return
function. But once the exception is raised, nothing 
else executes:
>>> call_exceptor()
call_exceptor starts here...
I am about to raise an exception
Traceback (most recent call last):
File "", line 1, in
File "method_calls_excepting.py", line 9, in call_exceptor
no_return()
File "method_calls_excepting.py", line 3, in no_return
raise Exception("This is always raised")
Exception: This is always raised
We'll soon see that when the interpreter is not actually taking a shortcut and exiting 
immediately, we can react to and deal with the exception inside either method. 
Indeed, exceptions can be handled at any level after they are initially raised.
Look at the exception's output (called a traceback) from bottom to top, and notice 
how both methods are listed. Inside 
no_return
, the exception is initially raised.
Then, just above that, we see that inside 
call_exceptor
, that pesky 
no_return
function was called and the exception bubbled up to the calling method. From
there, it went up one more level to the main interpreter, which, not knowing
what else to do with it, gave up and printed a traceback.
Handling exceptions
Now let's look at the tail side of the exception coin. If we encounter an exception 
situation, how should our code react to or recover from it? We handle exceptions 
by wrapping any code that might throw one (whether it is exception code itself, or
a call to any function or method that may have an exception raised inside it) inside
a 
try
...
except
clause. The most basic syntax looks like this:
try:
no_return()
except:
print("I caught an exception")
print("executed after the exception")
www.it-ebooks.info

---

Chapter 4