1 17-Exceptions

Next: 16-TypeFormatDebug.html

**There are no exceptions to the rule, that everybody likes to be an exception to the rule.**
    **- Charles Osgood**

1.1 Screencasts

• Password for the Vimeo videos is in Zulip chat.
• https://vimeo.com/530462886
• Tip: If anyone want to speed up the lecture videos a little, inspect the page, go to the browser console, and paste this in:
  document.querySelector('video').playbackRate = 1.2

1.2 Extra reading

• http://scipy-lectures.org/intro/language/exceptions.html
• https://docs.python.org/3/library/exceptions.html
• https://docs.python.org/3/tutorial/errors.html
• https://python.swaroopch.com/exceptions.html
• https://realpython.com/courses/introduction-python-exceptions/
• https://realpython.com/lessons/introduction-exceptions/
• https://realpython.com/python-exceptions/
• https://www.learnpython.org/en/Exception_Handling
• https://www.python-course.eu/python3_exception_handling.php
• https://www.tutorialspoint.com/python/python_exceptions.htm
• https://www.tutorialspoint.com/python3/python_exceptions.htm

1.3 Introduction

1.3.1 Abstract problem

• When writing an algorithm to solve a problem in the general case, often special cases must be addressed.
• Some might occur only rarely.
• Adding rare cases to the algorithm may increase it’s complexity or decrease its clarity.
• Performing error handling via return statements ends up intricately linked to the normal control flow of the code, constraining both how the code is laid out, and how errors can be reasonably handled.
• Ideally, express the algorithm in general form including any common special cases.
• Rare exceptional situations, along with a strategy to handle them, could ideally appear elsewhere, like an annotation to the algorithm.

1.3.2 Practical solution

Exception handling
* is a process of handling exceptional situations that may occur in a program.
* allows programmers to cleanly separate the code that implements the focused algorithm, from the code that deals with exceptional situations that the algorithm may face rarely.
* Upon encountering an exception, the compiler/interpreter can:
* redirect program flow to an appropriate error-handling code segment, or
* terminate gracefully; i.e., it will give a proper message and then will terminate the program.
* Exception handling communicates the existence of a run-time problem or error, redirecting program flow from where it was detected, to where the issue can be handled.
* Un-handled exceptions stop program execution, but you can choose to manually handle exceptions to continue running.
* When an exception is created, it is also commonly called raising or throwing an exception.

1.3.3 Keywords

Keywords in python:
assert, try, raise, catch, finally

1.3.3.1 Simple assertions

`assert condition_that_should_be_true, "comment about error if it's not"`

When condition_that_should_be_true is False, i.e., not True, comment about error if it's not is printed, and the program is terminated.

1.3.3.2 Full exception handling

try:
    statements
    raise <obj/class> # optional, with optional obj itself
except:
    statements
else: # optional
    statements
finally: # optional
    statements

• try block watches for any exceptions that are thrown by any of the statements within the tabbed under try block (protected code)
  • raise keyword explicitly signals that an exception or error case has occurred, and is followed by an:
    • error code,
    • description of the problem, or
    • a custom exception class
  • You don’t always have to be the one to have written the raise statement, since python’s code itself, or other imported code may raise an exception.
  • Should an error occur in the try block, an exception is thrown (raised in python), which then causes the current scope to be exited, and also each outer scope (propagation) until a suitable handler (catch/except block) is found, garbage collecting or calling in turn the destructors of any objects in these exited scopes, if necessary.
• except keyword is used to define a catch block that handles exceptions for an exception type(s)
  • except must be in the same scope as try!!
  • an explicit raise, or a deeper error producing an internal raise can be in any scope below and within the try block.

1.3.4 Benefits

• Functions don’t need to return error codes, thus freeing their return values for program logic itself.
• Fewer functions need to exist to deal with errors.
• An exception jumps to a point in the call stack that can be designed handle the error.
• Exception stack-unwinding mechanism destroys/garbage-collects all objects in scope, according to well-defined rules after an exception is thrown.
• Cleaner separation between code that detects errors and the code that handles errors is possible.
• The algorithm is kept focused on solving the problem, and exceptional cases are handled elsewhere (a more satisfying functional aesthetic).
• This approach is more modular, and encourages the development of code that is cleaner, and thus is easier to maintain and debug.

1.4 Examples

Check out the code

1.5 Stack unwinding

Trace the execution: code after exception, until except block, is skipped

1.6 Some Python3 standard exceptions

The above image is an older subset, and the full tree of python3’s built-in exceptions is:
BaseException
+– SystemExit
+– KeyboardInterrupt
+– GeneratorExit
+– Exception
+– StopIteration
+– StopAsyncIteration
+– ArithmeticError
| +– FloatingPointError
| +– OverflowError
| +– ZeroDivisionError
+– AssertionError
+– AttributeError
+– BufferError
+– EOFError
+– ImportError
| +– ModuleNotFoundError
+– LookupError
| +– IndexError
| +– KeyError
+– MemoryError
+– NameError
| +– UnboundLocalError
+– OSError
| +– BlockingIOError
| +– ChildProcessError
| +– ConnectionError
| | +– BrokenPipeError
| | +– ConnectionAbortedError
| | +– ConnectionRefusedError
| | +– ConnectionResetError
| +– FileExistsError
| +– FileNotFoundError
| +– InterruptedError
| +– IsADirectoryError
| +– NotADirectoryError
| +– PermissionError
| +– ProcessLookupError
| +– TimeoutError
+– ReferenceError
+– RuntimeError
| +– NotImplementedError
| +– RecursionError
+– SyntaxError
| +– IndentationError
| +– TabError
+– SystemError
+– TypeError
+– ValueError
| +– UnicodeError
| +– UnicodeDecodeError
| +– UnicodeEncodeError
| +– UnicodeTranslateError
+– Warning
+– DeprecationWarning
+– PendingDeprecationWarning
+– RuntimeWarning
+– SyntaxWarning
+– UserWarning
+– FutureWarning
+– ImportWarning
+– UnicodeWarning
+– BytesWarning
+– ResourceWarning

See code and above links for more detail.

1.7 Language focus

Code (to be stepped through in spyder, since pudb won’t launch with errors in the file):
17-Exceptions/exceptions_00_overview.py

Next: 18-InputOutput.html