Author Dusty Phillips Reviewers

[
 103 
]
If we run this simple script using our existing 
no_return
function, which as we 
know very well, always throws an exception, we get this output:
I am about to raise an exception
I caught an exception
executed after the exception
The 
no_return
function happily informs us that it is about to raise an exception, 
but we fooled it and caught the exception. Once caught, we were able to clean up 
after ourselves (in this case, by outputting that we were handling the situation), 
and continue on our way, with no interference from that offensive function. The 
remainder of the code in the 
no_return
function still went unexecuted, but the
code that called the function was able to recover and continue.
Note the indentation around 
try
and 
except
. The 
try
clause wraps any code that 
might throw an exception. The 
except
clause is then back on the same indentation 
level as the 
try
line. Any code to handle the exception is indented after the 
except
clause. Then normal code resumes at the original indentation level.
The problem with the preceding code is that it will catch any type of exception. 
What if we were writing some code that could raise both a 
TypeError
and a 
ZeroDivisionError
? We might want to catch the 
ZeroDivisionError
, but
let the 
TypeError
propagate to the console. Can you guess the syntax?
Here's a rather silly function that does just that:
def funny_division(divider):
try:
return 100 / divider
except ZeroDivisionError:
return "Zero is not a good idea!"
print(funny_division(0))
print(funny_division(50.0))
print(funny_division("hello"))
The function is tested with 
print
statements that show it behaving as expected: