Java Fundamentals

1. Exception Handling

An exception is an unexpected unwanted event that disturbs the normal flow of a program.

try {
    // Read data from London file
} catch (FileNotFoundException ex) {
    // Use local file and continue normally
}

2. Runtime Stack Mechanism

For every thread, the JVM creates a runtime stack. Every method call made by that thread is stored in the corresponding stack.

• Each entry is called a Stack Frame or Activation Record.
• After a method completes, its stack-frame entry is removed.
• After all method calls complete, the stack becomes empty and is destroyed by the JVM before the thread terminates.

main()
  └── doStuff()
        └── doMoreStuff()

3. Default Exception Handling in Java

When an exception occurs inside a method, the method creates an exception object containing the exception name, description and location/stack trace, then hands the object to the JVM.

1. The JVM checks whether the current method contains exception-handling code.
2. If not, the method terminates abnormally and its stack frame is removed.
3. The JVM checks the caller method and continues this process up to main().
4. If no handler is found, the JVM passes responsibility to the Default Exception Handler.
5. The default handler prints exception information and terminates the program abnormally.

Exception in thread "main"
ExceptionName: description
    at ClassName.method(ClassName.java:line)
    at ClassName.main(ClassName.java:line)

4. Exception Hierarchy

The Throwable class acts as the root of the Java exception hierarchy and defines two major child classes: Exception and Error.

Throwable
├── Exception
│   └── RuntimeException
└── Error

Examples Mentioned in the Source

5. Checked and Unchecked Exceptions

The source describes checked exceptions as exceptions checked by the compiler for smooth runtime execution. If a checked exception can be raised, it must be handled using try/catch or declared with throws; otherwise a compile-time error occurs.

Unchecked exceptions are not checked by the compiler for handling. Examples include ArithmeticException, NullPointerException, ClassCastException, array/string index exceptions, IllegalArgumentException and NumberFormatException.

Fully Checked vs Partially Checked

6. Exception Handlers: try and catch

The source calls code that may raise an exception risky code. Risky code is placed inside a try block, while corresponding handling code is placed inside a catch block.

try {
    // risky code
} catch (Exception ex) {
    // handle code
}

7. Control Flow in try/catch

Case Studies

• Once an exception occurs anywhere in a try block, the remaining statements in that try block are not executed, even if the exception is handled.
• An exception can also occur inside a catch or finally block.
• An exception raised outside a try block always causes abnormal termination unless handled elsewhere by normal propagation.

8. Printing Exception Information

9. Multiple catch Blocks

The source recommends a separate catch block for each exception type when the handling differs between exception types.

try {
    BufferedReader br =
        new BufferedReader(new FileReader("abc.txt"));
} catch (ArithmeticException ex) {
    // handling code
} catch (FileNotFoundException ex) {
    // handling code
} catch (NullPointerException ex) {
    // handling code
} catch (Exception ex) {
    // handling code
}

10. finally Block

The finally block is the recommended place for cleanup code that should execute regardless of whether an exception is raised or handled.

• Cleanup code should not depend on the try block completing every statement.
• Cleanup code should not be placed only in catch because catch does not execute when there is no exception.
• The finally block normally executes whether an exception occurs or not, and whether it is handled or not.
• If a return statement occurs in try/catch, finally executes before the return is completed.

try {
    // risky code
} catch (Exception ex) {
    // handle code
} finally {
    // cleanup code
}

11. throw and throws

throw

The throw keyword is used to explicitly create/hand over an exception object to the JVM. The source highlights user-defined/custom exceptions as an important use case.

throw new ArithmeticException("/ by zero");

• After a throw statement, statements written immediately after it are unreachable.
• The thrown object must be a Throwable type.
• Throwing a null reference results in a NullPointerException.

throws

The throws keyword delegates exception-handling responsibility to the caller.

public void readFile() throws FileNotFoundException {
    // code that may raise the exception
}

12. Top Exceptions and Who Raises Them

The source divides exceptions/errors based on who raises them into JVM Exceptions and Programmatic Exceptions.

13. Java 7 Exception Handling Enhancements

Try-with-resources

• Reduces the need for explicit cleanup and reduces code length.
• Multiple resources can be declared using semicolons.
• Resources must be auto-closable.
• A resource is auto-closable when its class implements java.lang.AutoCloseable.
• I/O, database and network-related resources commonly implement this interface.
• AutoCloseable was introduced in Java 7 and contains close().
• Resource reference variables are implicitly final within the try block, so reassignment is not allowed.
• From Java 7, try-with-resources can be used without an explicit catch/finally block.

try (R1 r1 = ...; R2 r2 = ...; R3 r3 = ...) {
    // use resources
}

Multi-catch

try {
    // risky code
} catch (IOException | SQLException ex) {
    // common handling code
}

14. Exception Propagation and Re-throwing

Exception Propagation

If an exception is raised inside a method and is not handled there, the exception object is propagated to the caller method. The caller becomes responsible for handling it.

Re-throwing Exception

The source describes re-throwing as an approach that can be used to convert one exception into another exception type.

15. User-Defined Exceptions

If a programmer implements their own exception, it is called a user-defined exception.

The source states that a user-defined exception class should extend one of the following:

• Exception
• RuntimeException
• Throwable

class MyException extends Exception {
    public MyException(String message) {
        super(message);
    }
}

16. Examples from the Source PDF

The later pages of the PDF contain practical exception examples, program output and exception traces. These pages are preserved below as page images so the original code screenshots, console output and diagrams remain available.

17. Quick Revision