A good answer might be:

The stack trace shows the chain of method calls that lead to the one that caused the exception, something like this:

java.lang.IOException:  some message
        at  some Java IO method
        at  Passing.methodC
        at  Passing.methodB
        at  Passing.methodA
        at  Passing.main 

In an actual stack trace, line numbers would be listed for each method.

Any method in the chain of calling methods can catch the exception. For example, the following would be another organization of the program:

public class Passing
{

  public static void methodC() throws IOException
  {
     // Some I/O statements
  }

  public static void methodB() throws IOException
  {
     methodC();
  }

  public static void methodA()  
  {
     try
     {
       methodB();
     }
     catch ( IOException ex )
     {
       // statements to handle the exception
     }

  }

  public static void main ( String[] a )  
  {
     methodA();
  }

}

A method may handle some exceptions and throw others. Some exceptions it handles may have originated in methods it called, others may originate in itself. There may be as many try/catch/finally structures in a method as needed. The error handling logic of "industrial strength" programs can take up more lines of code than the "real" purpose of the program.

If a method might originate checked exceptions of several classes, the throws clause looks like this:

throws ExceptionClass1, ExceptionClass2, ...

Unchecked exceptions do not need to be listed in a throws clause, even if a method might cause one and does not catch it.

QUESTION 8:

(Memory Test: ) Is an ArithmeticException a checked exception?