1. CIT 590 Intro to Programming Lecture 3

2. Pair programming logistics You and your partner submit 1 assignment Figure out who the submitter will be PLEASE write the name of you and your partner. I wish I could write a filter that rejects submissions that do not have this … You and your partner get the same grade Your partner this week will not be your partner next week

3. Pair programming http://www.realsearchgroup.com/pairlearning/ppflash.php http://research.microsoft.com/pubs/75108/esem-begel- 2008.pdf http://research.microsoft.com/pubs/75108/esem-begel- 2008.pdf

4. Agenda Recursion Throwing exceptions Functions returning nothing Debugging

5. Recursion A function calling itself Factorial def factorial(n): if n == 0: return 1 return n * factorial(n-1) numToString example from the book

6. Recursion pitfall Not having a base case Errors out very much like an infinite loop If you have seen mathematical induction This about the base case as the first step of induction Always always write the base case first. After all, it is supposed to be the easy case, so let’s do that first

7. Recursion pitfall number 2 Doing fibonacci with and without recursion How many recursive calls is fibonacci making 2 for each call. 1 + 2 + 4 + … and this summation is increasing exponentially In this case an alternate solution is easy. (iterativeFibonacci.py)

8. Agenda Recursion Throwing exceptions Functions returning nothing Debugging

9. Exceptions Handling unexpected situations Halt the execution so that the potential error does not propagate and cause an even bigger one ‘defensive programming’ Example – romanToDecimalConversion.py

10. Agenda Recursion Throwing exceptions Functions returning nothing Debugging

11. Functions that return nothing The NoneType used fairly often to initialize the value of a variable when you do not know what it might eventually hold

12. Agenda Recursion Throwing exceptions Functions returning nothing Debugging

13. Software is full of bugs! Murphy’s law adapted to Software Engineering says Every non trivial program has at least one bug Corollary 1 - A sufficient condition for program triviality is that it have no bugs. Corollary 2 - At least one bug will be observed after the author leaves the organization How do we figure out what is going on?

14. Debugging Old school print statements Never underestimate the power of dumping information Take out your log statements before submitting code Else you will be publicly shamed …or worse

15. IDLE debugger Breakpoints Stepping into and over Go starts the program. It runs until it hits another breakpoint, waits for keyboard input, or the program ends. Step executes the next statement. If it is the breakpointed statement, that statement is executed. If the statement is a function call (as this one is), the debugger enters the called function Over executes the next statement as step does, but does stay in the current code. It does not enter any functions. Out exits the function that it is in, returning control to the caller. Quit ends the program

16. Summary Recursion Throwing exceptions IDLE debugger