Problem 4: Handling Exceptions (0 pts)
Note: DO NOT start this problem before you submit the whole lab! The requirements of this problem conflict with the previous problems and may influence your score.
The interpreter we have so far is pretty cool. It seems to be working, right? Actually, there is one case we haven't covered. Can you think of a very simple calculation that is undefined (maybe involving division)? Try to see what happens if you try to compute it using your interpreter (using floordiv
or truediv
since we don't have a standard div
operator in PyCombinator). It's pretty ugly, right? We get a long error message and exit our interpreter -- but really, we want to handle this elegantly.
Try opening up the interpreter again and see what happens if you do something ill defined like add(3, x)
. We just get a nice error message saying that x
is not defined, and we can then continue using our interpreter. This is because our code handles the NameError
exception, preventing it from crashing our program. Let's talk about how to handle exceptions:
In lecture, you learned how to raise exceptions. But it's also important to catch exceptions when necessary. Instead of letting the exception propagate back to the user and crash the program, we can catch it using a try/except
block and allow the program to continue.
try:
<try suite>
except <ExceptionType 0> as e:
<except suite 0>
except <ExceptionType 1> as e:
<except suite 1>
...
We put the code that might raise an exception in the <try suite>
. If an exception is raised, then the program will look at what type of exception was raised and look for a corresponding <except suite>
. You can have as many except suites as you want.
try:
1 + 'hello'
except NameError as e:
print('hi') # NameError except suite
except TypeError as e:
print('bye') # TypeError except suite
In the example above, adding 1
and 'hello'
will raise a TypeError
. Python will look for an except suite that handles TypeError
s -- the second except suite. Generally, we want to specify exactly which exceptions we want to handle, such as OverflowError
or ZeroDivisionError
(or both!), rather than handling all exceptions.
Notice that we can define the exception as e
. This assigns the exception object to the variable e
. This can be helpful when we want to use information about the exception that was raised.
>>> try:
... x = int("sicp rocks!")
... except ValueError as e:
... print('Oops! That was no valid number.')
... print('Error message:', e)
You can see how we handle exceptions in your interpreter in repl.py
. Modify this code to handle ill-defined arithmetic errors. Specifically, after your modification, when you open your interpreter and try the following expressions, the raised exceptions should be handled elegantly, instead of rudely making the interpreter exit.
python repl.py
> truediv(4, 0)
ZeroDivisionError: division by zero
> floordiv(3, 0)
ZeroDivisionError: integer division or modulo by zero
> sub(add,1)
TypeError: Invalid arguments <primitive function add>, 1 to <primitive function sub>
You do not need to submit your answers to Problem 5, but you should cherish this opportunity to understand the exception handling mechanism.