1. 1 The Call Stack (Exceptions revisited)

2. 2 The Call Stack When method calls are made, the programming language must keep track of who called who  … and where to jump back to when method is finished This is done with the “call stack”  a list of the methods that have been called to get to the current code

3. 3 The Call Stack If a method privateMethod() is running now, the stack might look like this: privateMethod() obj.someMethod() doStuff() main() called

4. 4 Returning Values When methods return a value, it is passed back and the original call is removed privateMethod() obj.someMethod() doStuff() main() called returns

5. 5 Storing The call stack is stored in memory by the Java virtual machine All of the method’s parameters and local variables and parameters are part of its entry on the stack  this is why recursive calls all run separately: different calls and variables on the call stack

6. 6 Recursion on the Stack Since local variables and parameters are stored on the stack, recursive calls work: binSearch(2,4) binSearch(0,4) binSearch(0,8) main() called Each has it’s own local variables

7. 7 Exceptions and the Stack When a method throws an exception, that gets passed (instead of return value) privateMethod() obj.someMethod() doStuff() main() called SomeException throw new SomeException(); program stops

8. 8 Stack Display When an exception halts the program, the output is a representation of the call stack Exception in thread “main” SomeException at MyClass.privateMethod(MyClass.java:8) at MyClass.someMethod(MyClass.java:56) at MainProg.doStuff(MainProg.java:31) at MainProg.main(MainProg.java:127) This stack trace corresponds to the previous example

9. 9 Catching Exceptions If an exception is caught, its propogation stops and the function returns as usual: privateMethod() obj.someMethod() doStuff() main() called SomeException throw new SomeException(); returns normally catch(SomeException e)

10. 10 Designing with Exceptions An exception should occur if some uncommon condition occurs that the function can’t handle  shouldn’t happen if all goes well An exception should be used in “exceptional” circumstances where the function can’t recover by itself The function should throw an exception  throw new TypeOfException(“error message”);

11. 11 Example name.length() student.getNameSize() doStuff() – defines student with no name main() called NullPointerException return normally throw new NullPointerException(); returns normally catch(Exception e)

12. 12 Designing with Exceptions Some function up the call stack should catch the exception: catch(TypeOfException e)  whatever function can actually handle the problem should do so e.g.  user input function throws InputMismatchException, menu function catches it and asks for another choice  network IO function can’t read a webpage, main program pops up error message