Interfaces, Nested Interfaces, Inner Classes and Exception Handling

# Interfaces, Nested Interfaces, Inner Classes and Exception Handling

21.1 Interfaces — The Blueprint of a Class

21.1.1 What an Interface Is and the Blueprint Analogy

An interface (a blueprint of a class), written with the keyword interface, is a type that declares what a class must do without saying how it does it. The professor's anchoring picture — carry it through the whole lecture — is an architect's blueprint: it lists every room a house must have, but it leaves wall colour, flooring, and furniture to the builder.

Mapping the analogy explicitly:

• Blueprint sheet = interface named, say, Printable or abc.
• Room label on the sheet = method declaration such as void print(); — a promise that a room exists.
• Built house = concrete class such as Trial or BankAccount that supplies walls and wiring — the method body in curly braces { ... }.
• Building inspector = compiler: it checks that every room on the sheet appears in the house, with exactly the signature listed.

Where the analogy breaks: a real blueprint can be vague ("a bedroom about 12 ft by 14 ft"). A Java interface is exact: the signature void print(); fixes return type, name, and parameter list. The builder cannot substitute void print(String s).

This contract rule is absolute. If you write class Trial implements Printable, you promise to supply a body for every method Printable declares. Miss one and the compiler refuses to compile — the same strictness you saw earlier with an abstract class (a class that contains at least one declaration without a body and forces a subclass to define it), but an interface is syntactically lighter and intentionally incomplete: it was designed to be pure contract, not partial implementation.

A tiny concrete declaration makes the idea tangible:

interface abc {
    void print();
    void show();
}

abc lists two rooms. No curly-brace bodies appear — each line ends with ;. Any class that later writes implements abc must, in that class body, open void print() { ... } and void show() { ... } and fill them. The interface forces the contract: if you say you implement me, you must implement all of me.

The same blueprint can be implemented in many different classes, each giving its own body. This one-to-many relationship is the source of polymorphism you met in Icon or Callback examples: unrelated classes honour the same contract, so client code can call through the interface reference without knowing which builder built the house.

This blueprint idea maps directly to Java API design where teams publish an interface and many independent implementations conform to it — frameworks publish List or Stack as contracts and let ArrayList, LinkedList, FixedStack, DynStack all supply their own bodies.

21.1.2 Abstract Methods and Static Constants

Two phrases define the member model of a classic interface. They are worth naming precisely because the exam tests them.

First, its methods are abstract methods — declared without a body. An abstract method (a method header with no implementation) consists of a return type, a name, a parameter list, and a terminating semicolon. You write void print(); and you stop. The curly-brace body lives later, in the implementing class. The word abstract here means "body intentionally missing — to be supplied by someone else."

Second, its data members are static constants. Unpack each word on first use:

• static (belongs to the type itself rather than to any single object) — you refer to it by the name of the type, as in Printable.min or SharedConstants.NO, not by new Printable().min.
• constant (a value that, once initialized, never changes) — in Java you achieve this with the keyword final (cannot be reassigned after initialization).

So an interface field such as int min = 5; is not a per-object variable you mutate later; it is a shared, type-level constant whose value stays at 5 for every use. Under the hood the compiler treats it as one copy shared by all code, not one per object.

[public] interface InterfaceName {
    // abstract method: no body, ends with ;
    returnType methodName(parameterList);
    // constant: implicitly public static final
    type CONSTANT_NAME = value;
}

A concrete illustration with both kinds of members:

interface SharedConstants {
    int NO = 0;          // constant
    int YES = 1;         // constant
    void callback(int p); // abstract method
}

NO and YES are shared constants. callback is an abstract declaration. A class Question implements SharedConstants or Client implements Callback does not declare its own NO — it inherits the constant as if it had defined public static final int NO = 0; itself, and it must supply public void callback(int p) { ... }.

21.1.3 Compiler-Added Modifiers — public, static, final and public abstract

Writing int min = 5; inside an interface looks minimal, but what the compiler sees is fully qualified. This is an ease-of-use facility: you may omit the modifiers, the compiler inserts them for you. The verbal description preserved from the lecture is exact — for data members the compiler adds the keywords public static final, and for methods the compiler adds public abstract.

Concretely, when you write inside an interface named Printable:

interface Printable {
    int min = 5;
    void print();
}

the compiler interprets it as:

interface Printable {
    public static final int min = 5;
    public abstract void print();
}

You never need to type these keywords when you author the interface, but they are present after compilation — you can verify with javap -c Printable and you will see public static final and public abstract in the bytecode listing. Writing them explicitly is legal but redundant; omitting them is idiomatic.

The design choice connects to the taxonomy rule that interface members are inherently public: a blueprint hidden in a drawer is useless. The same rule forces a nested interface declared inside another interface to be public — a point revisited in section 21.5.

21.1.4 Why Interfaces Have No Instance Variables and How Objects Are Created

Interfaces are syntactically similar to classes — both use curly braces { }, both list members — but they lack instance variables (per-object fields that each object carries separately, such as private int data or private int balance). The intuition the professor stressed: just as you cannot create a direct object of an abstract class with new AbstractClass(), you cannot write new Printable() as a freestanding construction.

Why not? An instance variable belongs to an object — it needs memory per object, a constructor to initialize it, and state to maintain. If you could fabricate an interface object directly by writing the interface name on both sides of the constructor call (Printable p = new Printable();), you would be pretending the incomplete blueprint is a complete house. There is no body for print(), no storage for per-object state, no constructor to run.

What you can do is create an object through a reference to an existing concrete class that implements the interface, and refer to it through the interface type. The dynamically looked-up method then runs the implementing class's body.

interface Callback {
    void callback(int param);
}
class Client implements Callback {
    public void callback(int p) {
        System.out.println("callback called with " + p);
    }
}
Callback c = new Client(); // legal: Client object, Callback reference
c.callback(42);            // dispatches to Client's body at runtime

c is declared as Callback but points to a Client object. The call c.callback(42) is resolved at runtime to Client.callback. The same Printable blueprint can likewise be implemented in many different classes, each giving its own body to the declared methods — exactly the one-interface-multiple-implementations pattern shown with FixedStack/DynStack or Client/AnotherClient.

Visual intuition — picture a class hierarchy diagram with Throwable at the top, branching to Exception and Error, and a separate, parallel hierarchy for interfaces: a dashed box labelled Printable (no instance fields, dashed methods print()) with solid arrows implements pointing from two solid class boxes Client and AnotherClient, each containing a filled print() body and a per-object field like size. The x-axis is "completeness" (dashed = incomplete, solid = complete); the y-axis is number of implementations. The takeaway: one dashed contract fans out to many solid implementers; the inspector arrow (compiler) enforces coverage.

Real-world and domain placement — Outside the lecture hall, every major Java framework publishes interfaces as stable contracts: java.util.List with many implementations (ArrayList, LinkedList, Vector), JDBC's Connection and Statement implemented differently by each database vendor, and the IntStack example you will extend with defaults. The blueprint contract lets teams evolve implementations independently; the compiler's public static final / public abstract insertion is what makes the published constants and method promises uniform across all those implementations.

21.2 Class-Interface Relationships and Multiple Inheritance

21.2.1 The Three Relationships — extends, implements and interface extends interface

Three distinct keywords govern how types relate, and the professor made the taxonomy strict because the compiler enforces it character-for-character.

• A class extends another class. You write class B extends A for ordinary inheritance of state and behavior. B inherits fields and method bodies from A, may override them, and there is an is-a relationship: every B is an A.
• A class implements an interface. You write class XYZ implements ABC where ABC is an interface. The word implements signals you are taking on the interface contract — you must supply bodies for every public abstract method ABC declares, each declared public in the class.
• An interface extends another interface. You write interface Showable extends Printable. This is the interface-to-interface line: inheritance of contracts, not of bodies. The child interface accumulates all method declarations of its parent(s) and may add more.

Note the vocabulary carefully: a class implements an interface, but an interface extends another interface; an interface never says it implements another interface. Writing interface Showable implements Printable is a compile error. Similarly, a class never "implements" a class — class B implements A where A is a class is also an error.

General form (from the reference docs) captures the multiplicity:

class ClassName [extends Superclass] [implements Interface1 [, Interface2 ...]] { ... }
interface InterfaceName [extends SuperInterface1 [, SuperInterface2 ...]] { ... }

A class may have at most one extends (single class inheritance) but many implements separated by commas. An interface may extend many interfaces at once, also comma-separated.

This taxonomy is strict and the compiler enforces it — wrong keyword choice is not a style issue but a cannot find symbol or 'implements' expected error that stops the build.

21.2.2 Worked Example — Bank, BankAccount and CheckingAccount Hierarchy

Setup: Define an interface Bank with two methods deductP() and withdraw(), both declared as void return type without bodies. No data members are present in this illustration. Think of Bank as a capability contract: any bank must be able to deduct penalty and allow withdrawal, but the regulation does not dictate how.

interface Bank {
    void deductP();   // public abstract, ends with ;
    void withdraw();  // public abstract, ends with ;
}

Step 1 — Implementing class. Create class BankAccount implements Bank. Because Bank is an interface, the methods deductP and withdraw are abstract. It becomes a necessity to define them inside BankAccount. You open curly braces after each and provide logic — whatever fee-deduction or withdrawal logic you choose. The mere presence of implements Bank forces both definitions or the program complains (BankAccount is not abstract and does not override abstract method).

class BankAccount implements Bank {
    private double balance;

    public void deductP() {
        balance -= 5.0; // example fee logic
        System.out.println("deducted penalty, balance = " + balance);
    }
    public void withdraw() {
        balance -= 100.0;
        System.out.println("withdrew, balance = " + balance);
    }
}

Note public is required on both bodies — the interface declarations are public abstract, so the implementer cannot weaken visibility.

Step 2 — Simultaneous inheritance and implementation. Create class CheckingAccount extends BankAccount implements Bank. Two keywords appear on the same header, and their order matters: extends first, then implements.

class CheckingAccount extends BankAccount implements Bank {
    public void deductP() {
        System.out.println("checking deduct with overdraft check");
    }
    // withdraw inherited from BankAccount if not overridden
}

What each keyword does here:

• extends BankAccount means CheckingAccount inherits everything from BankAccount, including any implementations it already gave for deductP and withdraw, and can override them as part of the inheritance hierarchy. It inherits the balance field, the ready-made bodies, and the is-a relationship: every CheckingAccount is a BankAccount.
• implements Bank means it also directly commits to the Bank contract again — redundant in this specific hierarchy (since BankAccount already satisfied it) but legal and pedagogically important: it states the intent that CheckingAccount itself directly honours Bank, not merely transitively through its parent.

Even if CheckingAccount chooses not to explicitly override the inherited deductP/withdraw, the compiler still demands that those methods be available — but they are, via inheritance. If the class provides new bodies, those bodies satisfy both the parent-class inheritance and the interface contract at once. The lesson the professor repeated for emphasis: in Java you may inherit a class with extends and implement an interface with implements on the same class simultaneously. This dual facility is the idiomatic way to give a class both state inheritance and capability contracts:

class MyClass extends SuperClass implements Interface1, Interface2 { ... }

Bank b1 = new BankAccount();      // Bank reference, BankAccount object
b1.deductP();   // dispatches to BankAccount.deductP  → "deducted penalty..."
b1.withdraw();  // dispatches to BankAccount.withdraw → "withdrew..."

Bank b2 = new CheckingAccount(); // Bank reference, CheckingAccount object
b2.deductP();   // dispatches to CheckingAccount.deductP → "checking deduct..."
b2.withdraw();  // inherits BankAccount.withdraw if not overridden

// Direct construction also legal:
CheckingAccount c = new CheckingAccount();
c.deductP(); c.withdraw();

21.2.3 Why Java Forbids Multiple Class Inheritance but Allows Multiple Interface Implementation

Java does not support multiple inheritance directly via classes. You cannot write class C extends A, B to inherit two or more concrete classes at once — the compiler rejects the comma after extends with cannot inherit from multiple classes.

The reason preserved in explanation: a class is complete — it carries defined state (instance fields) and method bodies — and inheriting two complete classes would create ambiguity about which body to use. If A and B each define void show() { ... } differently and C extends A, B inherits both, the call new C().show() has two competing bodies with equal claim. This is the classic diamond problem with state and behaviour.

An interface, however, is partial in its classic form: it carries only declarations (public abstract methods, public static final constants) and no per-object defined bodies and no per-object instance fields. Because it is not a complete class — the plumbing is not yet installed — the language permits you to combine several of them. There is no competing body to choose between when both Printable and Showable merely declare void show();. That is how multiple inheritance is achieved through interfaces: a class can implement more than one interface (class Trial implements Printable, Showable), and an interface can extend more than one interface (interface C extends A, B), without the compiler complaining.

The professor's re-explanation tied this directly to the public static final / public abstract model: because interface members imply no per-object instance state and (classically) no bodies, combining them introduces no state conflict — unlike combining two classes each with private int balance and divergent withdraw() logic.

Visual intuition — sketch two diagrams side-by-side. Left: two solid house icons A and B, each with filled pipes, converging with a big red X on C extends A, B — axes are "parent completeness" (solid = complete) vs "ambiguity" (high). Right: two dashed blueprint icons Printable and Showable (dashed outlines, no pipes), converging with a green check on class Trial implements Printable, Showable — one solid house Trial below supplying the single show() body. A dashed arrow labelled "default show() with body" pointing to a warning triangle marks the post-Java-8 special case where you must add InterfaceName.super.show(). Takeaway in one sentence: multiple blueprints are combinable because they are incomplete; multiple houses are not.

21.2.4 Worked Example — Printable and Showable Implemented Together

Setup: Two interfaces share method names. This is a distinct example from the bank example — intentionally minimal to isolate the multiple-inheritance mechanics.

interface Printable { void print(); void show(); }
interface Showable  { void print(); void show(); }

Both declare print and show with only declarations (public abstract, no bodies). No constants are present.

Construction: class Trial implements Printable, Showable using a single implements clause listing both interfaces separated by a comma. The order Printable, Showable versus Showable, Printable does not matter.

Obligation: Because Trial implements both, it must provide bodies for print and show. The bodies reside only here, each marked public:

class Trial implements Printable, Showable {
    public void print() { System.out.println("within print"); }
    public void show()  { System.out.println("within show"); }
}

Crucial clarification the professor belaboured: the name show appears in both interfaces, but neither interface contains a body for it. There is only one show definition in Trial, and it satisfies both interface declarations simultaneously. No disambiguation of the declaration source is needed at this stage because declarations have no bodies to choose between. The method signature match is exact — return type, name, parameter list — and that single body counts for all interfaces that declared it. The same holds for print.

Trial p = new Trial();
p.print(); // → within print   (Trial.print supplies body for both Printable.print and Showable.print)
p.show();  // → within show    (Trial.show supplies body for both declarations)

Printable pr = new Trial(); pr.show(); // → within show
Showable  sh = new Trial(); sh.show(); // → within show  (same body)

Comparison — sibling concepts side-by-side: Class multiple inheritance (extends two classes) is forbidden because of competing bodies and state; interface multiple inheritance (implements many interfaces) is allowed because there are no competing bodies in the classic model. When to pick which? Never write extends A, B — extract capability contracts as interfaces. Use implements when a class must be "printable and showable and sortable"; use extends when a class is a specialization of exactly one parent's state and behaviour (CheckingAccount is a BankAccount).

Real-world — This pattern is how a single service class in production conforms to several capability contracts at once, e.g. class ReportService implements Printable, Exportable, Auditable or a UI widget class MyIcon implements Icon, Comparable<MyIcon>. The one-body-satisfies-both-declarations rule keeps such multi-contract adoption lightweight until default bodies are involved.

21.3 Default Methods in Interfaces

21.3.1 The Evolution Problem Default Methods Solve

In the classic model, every method declaration in an interface must be defined in every class that implements it. That creates a painful evolution problem: if a published interface needs a new method, every existing implementation must be edited to add the new body or it stops compiling. The change is source-incompatible — the compiler demands the missing body.

A concrete story: IntStack is interface IntStack { void push(int item); int pop(); } and FixedStack and DynStack both implement it across many codebases. Adding void clear(); with the classic rule would mean FixedStack and DynStack each fail with does not override abstract method clear() until someone adds a body. For a widely used library interface (Collection, List, Stream), that would be catastrophic.

To overcome this, after Java 8, default methods were introduced. A default method (a method inside an interface that carries its own implementation and does not force every implementing class to override it) supplies a fallback body directly in the interface. The keyword default marks that fallback.

Why the name "default"? Because it is the body used by default when the implementing class supplies none. The professor stressed the motivation as library evolution without breakage, and as optional functionality: a method such as remove() or clear() may be meaningful for modifiable sequences but not for non-modifiable ones. Supplying a default that does nothing or throws UnsupportedOperationException lets non-modifiable implementers ignore it without writing a dummy skeleton implementation.

The defining difference between interface and class still holds: even with defaults, an interface cannot maintain per-object state (no instance variables). It can specify behaviour fallback, but it cannot store that behaviour's state. So default is a special-purpose escape hatch for evolution, not a license to turn interfaces into classes.

21.3.2 Syntax of Default Methods — the default Keyword

You create a default method by prefixing the method header with the keyword default and then supplying a body in curly braces — unlike a classic declaration which terminates with ;. The placement matters: default comes before the return type, after any public (which is implicit).

interface Printable {
    void print(); // classic: public abstract, ends with ;
    default void show() {
        System.out.println("within show of Printable");
    }
}

interface IntStack {
    void push(int item); // store an item
    int pop();           // retrieve an item
    // Because clear() has a default, it need not be
    // implemented by a preexisting class that uses IntStack.
    default void clear() {
        System.out.println("clear() not implemented.");
    }
}

default void clear() {
    throw new UnsupportedOperationException("clear not supported");
}

Notice the contrast deliberately preserved in the lecture: print is simply declared and terminated, while show is declared with default and accompanied by a body. The default keyword is what makes that fallback legal — without it, a body in an interface would be a compile error under the pre-JDK-8 interpretation (interface abstract methods cannot have a body).

A class may mix these: one interface can have both classic abstract declarations (compulsory) and default methods (optional), plus static helpers. The compiler enforces the distinction.

21.3.3 Worked Example — Printable with a Default show Method

Context: Printable has one abstract declaration void print(); and one default method default void show() with a body as above. This is the canonical minimal example that isolates the new behaviour.

interface Printable {
    void print(); // abstract, compulsory
    default void show() {
        System.out.println("within show of Printable");
    }
}

Implementing class — intentionally omits show:

class Trial implements Printable {
    public void print() {
        System.out.println("within print");
    }
    // no show implementation at all — legal because show is default
}

Key points line by line:

• class Trial implements Printable promises the compiler it will satisfy Printable. The compiler checks: print() is abstract → must be present — it is, with public void print() { ... }, so that promise is met. show() is default → presence is optional — the compiler allows omission.
• The class defines only print. It intentionally omits show. The program does not complain — Trial is concrete and not abstract — which is the whole point of default. Before JDK 8 this would have forced Trial to be abstract or to supply show.
• The public on print() is still required (see section 21.1 pitfalls).

21.3.4 Calling Behavior When a Class Omits the Default Implementation

Driver in a class with main:

Trial p = new Trial();
p.print(); // direct control to Trial's print definition
p.show();  // searches Trial for show, finds none, falls back to Printable's default show

Resolution order — precisely what the professor traced:

1. p.show() looks first for a definition inside Trial. Resolution is by runtime type: p is a Trial object, so the VM checks Trial.show.
2. When none is found, control falls back to the interface and executes the default implementation provided there — within show of Printable is printed.
3. The keyword default is what makes that fallback legal: it tells the compiler "this interface method has a body that may be used as fallback."
4. If a class does supply show, its version overrides the default — class priority beats interface default (the first rule in the conflict resolution list). So:

class Trial2 implements Printable {
    public void print() { System.out.println("within print"); }
    public void show()  { System.out.println("my own show"); }
}
Trial2 t2 = new Trial2(); t2.show(); // → my own show  (Trial2 wins over Printable default)

Trial p = new Trial();
p.print(); // → within print               (direct, class body)
p.show();  // → within show of Printable   (no class body, default fallback)

Trial2 t2 = new Trial2();
t2.show(); // → my own show                (class body overrides default)

The same dispatch story holds through an interface reference — polymorphism applies:

Printable pr = new Trial();
pr.print(); // → within print  (Trial)
pr.show();  // → within show of Printable (default, no Trial override)

The lecture used this to emphasize that default methods preserve late binding: the VM still selects by actual object type, preferring class body over default.

Picture a stack of three layers: bottom — dashed interface Printable with print() (red, abstract, no body) and show() (green, default with filled body). Middle — optional solid class Trial that may or may not supply its own show (transparent vs solid green box). Top — arrow p.show() dropping down, hitting the class box first; if the box is transparent (no body), the arrow passes through to the green default below — labelled "fallback". X-axis is "lookup order" (class first, then interface), y-axis is "presence". One-sentence takeaway: calls check the class first; only when the class is silent does the interface's default speak.

21.3.5 Student Questions and Answers

Comparison to cement the distinction: classic void print(); ends with ; and mandates a class body; default void show() { ... } ends with { ... } and permits omission. One is compulsory, one is fallback.

Real-world — Library maintainers use default methods to add new capabilities to long-published interfaces without breaking thousands of downstream implementations. Java's own Collection interface added default boolean removeIf(...), default Stream<E> stream(), and default void forEach(...); List added default void sort(...). Each was shipped as a default so code compiled against older JDKs kept compiling while newer implementers could override for better performance.

21.4 Static Methods in Interfaces and Default Methods Under Multiple Inheritance

21.4.1 Static Methods Inside Interfaces

Just as you can have default methods with bodies, you can have static methods with bodies inside an interface (added alongside defaults in JDK 8). A static method (a type-level method — a class method — whose invocation is tied to the type name, not to an object instance) never dispatches on an object; it is resolved by the type that owns it.

Syntax: prefix the method header with static, then supply the body in curly braces. Like defaults, static interface methods are implicitly public when written without an access modifier.

interface Printable {
    void print(); // abstract, instance-level, compulsory
    static void show() {
        System.out.println("within static show");
    }
}

The interesting point the professor emphasized: this is a definition inside the interface, permitted alongside default methods, and it behaves like any other static member (like public static final constants) — one copy owned by the type. You would put here helpers or factories that conceptually belong to the interface namespace rather than any single implementation, e.g. a static Printable.createDefault() or a validator Printable.isValid(String s).

Since JDK 9 you can also write private and private static helper methods inside interfaces — visible only within the same interface — to share code between multiple defaults/statics without exposing it to implementers. The lecture focuses on the public static form most relevant for the exam.

21.4.2 Worked Example — Calling a Static Interface Method by Interface Name

Construction: class Trial implements Printable { public void print(){ System.out.println("within print"); } } The class ends after print; no show body is present — there is nothing to add, because show is static and lives on the interface type, not on the implementing class's instance.

interface Printable {
    void print(); // abstract
    static void show() {
        System.out.println("within static show");
    }
}
class Trial implements Printable {
    public void print() {
        System.out.println("within print");
    }
    // no show — static show is not an instance method to implement
}

Driver in another class (e.g., a client with main):

Trial t = new Trial();
t.print();          // instance call, resolved to Trial.print → within print
Printable.show();   // static call by interface name → within static show

Why not t.show()? Because show is static and lives on the interface type Printable itself — analogous to calling a static class method by ClassName.method(). You call a static interface method by the name of the type that owns it, not through an object reference. Writing t.show() where show is static will either fail (cannot make static reference to non-static confusion in older idioms) or, if the compiler permits it with a warning, be resolved as Printable.show() at compile time — but the idiomatic and exam-expected form is Printable.show(). The lecture flagged this as an exam note: expect a question asking how to invoke a static interface method; answer is by interface name.

interface Printable {
    void print();
    default void instanceShow() { System.out.println("default instance"); }
    static void staticShow()    { System.out.println("static"); }
}
class Trial implements Printable {
    public void print() {}
    public void instanceShow() { System.out.println("overridden instance"); }
}
Trial t = new Trial();
t.print();              // → (Trial body)
t.instanceShow();       // → overridden instance  (instance dispatch, class wins)
Printable.staticShow(); // → static                (type dispatch, no override possible)
// t.staticShow();       // ← not idiomatic; exam expects Printable.staticShow()

For print, which is an instance-level abstract method given a body in Trial, you always call via the object t.print() and it dispatches polymorphically. For show which is static on the interface, you always call via the interface name Printable.show() and it never dispatches polymorphically.

21.4.3 Two Default show Methods — the Conflict Scenario

Now combine default methods with multiple inheritance. Two interfaces each provide their own default show — each with a body, each with the same signature — to set up the diamond where the same signature has two competing default bodies.

interface Printable {
    void print(); // still abstract
    default void show() { System.out.println("within show of Printable"); }
}
interface Showable {
    void print(); // still abstract
    default void show() { System.out.println("within show of Showable"); }
}

So print is simply declared in both (no body, no conflict — one body later satisfies both), while show is defined in both as a default method, each with its own body. This is the crucial shift from the earlier single-default example: previously there was at most one body to fall back to, so omission was allowed. Now there are two equally valid fallbacks for the same signature, and silence is no longer disambiguation.

This sets up the classic default-method diamond — interfaces P and Q both default show(), class Trial implements P, Q sits at the tip. The question becomes: which default would t.show() pick? The answer is: the compiler refuses to pick — it requires the class to choose explicitly.

Visual — draw the diamond: top nothing, middle layer two dashed boxes Printable and Showable each containing a green default show() box with different text; bottom solid box Trial implements Printable, Showable with a red warning triangle on show labelled "two defaults → must override". Arrows from Trial.super.show go up separately to Printable.super.show and Showable.super.show. Takeaway: two green defaults at the same level cannot both be the fallback — the tip must write its own body.

21.4.4 Worked Example — Resolving Conflicts with InterfaceName.super

Construction: class Trial implements Printable, Showable where both supply default void show() as above.

If Trial omits any show, the compiler cannot choose between the two defaults and will complain (see scope). You must resolve explicitly by overriding show() in Trial and, inside that overriding method, explicitly delegating to whichever default(s) you want via qualified super calls.

class Trial implements Printable, Showable {
    public void print() { System.out.println("within print"); }
    public void show() {
        Printable.super.show(); // invoke Printable's default
        Showable.super.show();  // invoke Showable's default
    }
}

Inside Trial.show, the two lines Printable.super.show() and Showable.super.show() each invoke one interface's default. The qualifier InterfaceName.super is the explicit disambiguator, borrowing the familiar super.method() concept from class inheritance where super.method() calls a parent's version. Because show exists in both interfaces, you prefix with the interface name, then a dot, then super, then a dot, then the method name. This is the prescribed Java syntax for reaching an interface default from the implementing class — and it is only legal inside Trial that declares implements Printable, Showable.

You are free to choose: call only one default, call both in sequence (as above), or supply an entirely new body without delegating at all. The cousin example from the reference docs — IntStack evolving with default void clear() — would have Trial override clear() and perhaps just not delegate if the default's "not implemented" print is unwanted.

Trial t = new Trial();
t.print(); // → within print
t.show();  // enters Trial.show, hits two delegations

Rules for the diamond summarized from the reference:

1. Class implementation always takes priority over interface default. So a public void show() in Trial beats both defaults unconditionally.
2. If a class implements two interfaces with the same default signature and omits its own body, compilation fails — you must override.
3. Inside the overriding body, InterfaceName.super.method() reaches that interface's default; this qualified super is only legal in the class that directly implements the interface.

A second real example — Alpha and Beta both default void reset() — the same rules apply; MyClass implements Alpha, Beta must public void reset(){ Alpha.super.reset(); } or its own body (page 249 of the companion text).

Driver restated for the lecture's two-line output case:

Trial t = new Trial();
t.print(); // System.out.println within print
t.show();  // first executes Printable's show, then Showable's show via the two super calls

21.4.5 Student Questions and Answers

Real-world — This pattern appears in Java's own collections and streams where interfaces evolved with defaults like Collection.forEach, List.sort, Collection.removeIf, and stream defaults. A class that implements two library interfaces that happened to add the same default name hits exactly this diamond; explicit InterfaceName.super delegation is how service adapters in large codebases resolve library-evolution diamond problems without renaming.

21.5 Nested Interfaces

21.5.1 Definition and Access Rules

Nesting means one entity inside another — you open the braces { } of an outer type and declare a second type inside. A nested interface is an interface declared within another interface or within another class. The phrase means exactly that lexical containment.

A minimal skeleton:

interface Outer {
    void outerMethod();
    interface Inner {      // nested interface
        void innerMethod();
    }
}
class OuterClass {
    interface Inner {      // nested interface inside a class
        void innerMethod();
    }
}

Core rules — the professor listed them as non-negotiable and examination-frequent:

• A nested interface cannot be accessed directly by its simple name alone when you are outside the outer type; it is referred to by the outer type name qualified with a dot: Outer.Inner. So outside Printable, the inner Showable is Printable.Showable, and outside a class A the member interface is A.NestedIF. This matches Outer.Inner and A.NestedIF in the companion docs example.
• If declared inside an interface, the nested interface must be public. It should be available publicly because interface members are inherently public (see section 21.1). Writing private interface Showable inside interface Printable is illegal. The illustration used Printable as outer and Showable as inner — both implicitly public.
• If declared inside a class, the nested interface can have any access modifier, because a class may control visibility more flexibly per the language rules: public, protected, private, or default (package) are all legal for an interface member of a class. You choose whether outside code may see it.
• Nested interfaces are implicitly declared as static. This point was made explicitly as part of the nesting rules: even without writing static, the inner interface is a type-level member that does not require an outer instance to exist. Writing interface Outer { static interface Inner { ... } } is redundant — the static is implied.

These rules parallel member-class rules but with the interface-specific public-inside-interface constraint.

21.5.2 Implicit static Nature and Access-Modifier Constraints

The implicit static means the inner interface does not require an instance of the outer type to exist; it is a type-level member, like a static constant. You do not need new Outer() to refer to Outer.Inner — you just write the qualified name.

Practically, this means Outer.Inner is loaded with Outer as a static member, not tied to any particular object. That is why you can implements Outer.Inner without holding an Outer instance, analogous to accessing Printable.min without constructing Printable.

The access-modifier distinction is worth belabouring because it is a frequent exam distractor:

• Inside an interface, you cannot hide the inner interface as private — it must be public (implicitly, even if you omit the keyword), because interfaces are about public contracts. Declaring interface Outer { private interface Inner { ... } } fails with illegal combination of modifiers.
• Inside a class, you may write public interface Inner, private interface Inner, protected interface Inner, or default interface Inner, depending on whether you want outside code to see it. A private inner interface is only visible within the outer class and is used for internal callbacks that should not leak.

Outer is interface  → Inner must be public (implicitly), implicitly static
                    reference as Outer.Inner
Outer is class      → Inner may be public / protected / private / default, implicitly static
                    reference as Outer.Inner; visibility follows the modifier

Only inner interfaces and inner classes can be static; you cannot write static interface Outer at the top level, for the same reason you cannot write static class Outer at top level — static only makes sense for a member, and a top-level type has no enclosing member to be static with respect to.

21.5.3 Worked Example — Interface Within Interface — Outer vs Inner

Outer vs inner illustration — the canonical pair the lecture dissected case-by-case:

interface Printable {
    void print();
    interface Showable {
        void show();
    }
}

Here Printable is outer, Showable is inner (nesting of interfaces). Printable declares print (compulsory if you implement outer); Showable declares show (compulsory only if you implement inner). The inner is implicitly public static.

Case 1 — Implementing only the outer.

class Trial implements Printable {
    public void print() { System.out.println("within print"); }
    public void show()  { System.out.println("within show of Trial"); }
}

In driver, Trial p = new Trial(); p.print(); p.show(); works. Why can p.show() be called? Note carefully — and the lecture flagged this as the examinable subtlety — this show in Trial is a local method of Trial itself, not the inner interface's show. Nowhere in this variant does the class header mention Showable. So this show should not be confused with the show declared in Showable; it is just a coincidentally same-named ordinary method that Trial happens to have. The compiler does not link it to Printable.Showable.

Critical follow-up question addressed in detail: What happens when the implementation of show is removed from Trial in this case?

If you delete public void show(){...} from Trial in this case, nothing is going to happen and no compilation complaint is raised. The outer interface Printable only declares print; it does not have access to the inner interface Showable — nesting is lexical containment, not inheritance. Because Trial is declared as implements Printable, print becomes compulsory to define, but Showable is never referenced, so its show is not compulsory. The show you saw in Trial was a local addition, and removing it simply means the corresponding p.show() call in main must also be removed; otherwise you call a non-existent method on Trial. No interface contract is violated. The inner Showable sits untouched.

// With Trial's own show
class Trial implements Printable {
    public void print(){ System.out.println("within print"); }
    public void show(){ System.out.println("within show of Trial"); } // not from interface
}
Trial p = new Trial(); p.print(); // → within print
p.show();              // → within show of Trial (local method, not interface obligation)

// After deleting show from Trial — still compiles
class Trial implements Printable {
    public void print(){ System.out.println("within print"); }
}
Trial p = new Trial(); p.print(); // → within print  (only contract)
 // p.show(); // ← now compile error: Trial has no show() at all — local method gone

Case 2 — Implementing the inner.

class Trial implements Printable.Showable {
    public void show() { System.out.println("within show"); }
}

Now the header says Printable.Showable — the inner interface qualified by the outer. This says explicitly: I am taking on the inner contract, not the outer one. Therefore show, which is declared inside Showable, becomes compulsory to define, and the body is provided accordingly. Note print() is not required now — you did not implement Printable. Driver:

Trial t = new Trial();
t.show(); // → within show — delegates to Trial's show which satisfies Printable.Showable
// t.print(); // ← error: Trial has no print — outer not implemented

If you omit the implementation of show here, you get a compilation error: Trial is not abstract and does not override abstract method show() in Printable.Showable — the class is explicitly implements Printable.Showable and therefore must define show. This contrast between Case 1 and Case 2 is the core lesson: implementing the outer does not pull in the inner; implementing the inner must be stated as Outer.Inner.

Picture the containment as Russian nesting dolls: the outer doll labelled Printable (contains print()), a smaller doll inside labelled Showable (contains show()). An arrow implements Printable points only to the outer doll — it does not reach inside. An arrow implements Printable.Showable threads through the outer wall to point directly at the inner doll. X-axis is nesting depth, y-axis is obligation. Takeaway: Outer and Outer.Inner are distinct contracts; you name the one you take on.

21.5.4 Worked Example — Interface Within Class and Class Within Interface

Interface within class — the next permutation, swapping which kind of type is outer:

class Printable {
    public void print() { System.out.println("within print of outer class"); }
    interface Showable {
        void show(); // implicitly public abstract, implicitly static
    }
}
class Trial implements Printable.Showable {
    public void show() { System.out.println("within show"); }
}

How to implement: refer via Printable.Showable using the outer class name followed by inner interface name — same Outer.Inner qualified rule. Then show must be defined (it is the inner interface's abstract method). Driver:

Trial t = new Trial();
t.show();  // → within show — satisfies Printable.Showable
// t.print(); // DOES NOT WORK — compile error

Why t.print() fails: print belongs to the outer class Printable, not to the inner interface Showable. Trial implements only Printable.Showable, the inner interface, so it inherits the contract of show but does not inherit the instance method print of the outer class. To call print, you need an object of Printable itself (Printable pr = new Printable(); pr.print();), or you must extend the outer class, not implement its inner interface. Because this is a clean case of implementing an inner interface, Trial can only guarantee show. The qualified name matters more than the coincidence that print and show live in the same file.

The access-modifier flexibility appears here: because Showable lives inside a class, its declaration could be public interface Showable, protected interface Showable, private interface Showable, or default — controlling whether Trial outside the package can see Printable.Showable at all.

Class within interface — the opposite nesting (the mirror image):

interface Showable {
    void show(); // abstract
    class Printable {
        public void print() { System.out.println("within print"); }
    }
}
class Trial extends Showable.Printable {
    public void show() { System.out.println("within show"); } // not overriding yet
}

Key vocabulary shift the professor highlighted: Printable is now a class inside an interface. A class is inherited, not implemented. So you write extends Showable.Printable using extends (because you are inheriting a class) and qualify with the outer interface name — Showable.Printable — exactly the same Outer.Inner dot rule, but with extends instead of implements because the inner type is a class.

Inside a class-inside-interface, the inner class is implicitly public static in the same way the inner interface was — it does not require an outer instance. Its print() is a concrete instance method, inherited normally.

Driver:

Trial t = new Trial();
t.show();  // → within show  (defined in Trial — but see next case for obligation)
t.print(); // → within print (inherited from Showable.Printable, callable via derived object)

Output: first within show, then within print. No error occurs when calling print via a Trial object because inheritance makes parent class methods available on the child object — Trial is-a Showable.Printable, so print is inherited like any extends parent. This contrasts with the previous case where you could not call print via Trial because you were implementing an interface, not extending a class — you only acquired a contract, not a concrete parent body.

// Interface inside class — implements
class Printable { interface Showable { void show(); } }
class Trial implements Printable.Showable {
    public void show(){ System.out.println("show"); }
}
Trial t = new Trial(); t.show(); // ok
// t.print(); // fails — not inherited, only Showable was implemented

// Class inside interface — extends
interface Showable { class Printable { public void print(){...} } }
class Trial2 extends Showable.Printable { }
Trial2 t2 = new Trial2(); t2.print(); // ok — inherited via extends
// t2.show(); // fails unless Trial2 also implements Showable — see next case

21.5.5 Worked Example — Combined Inheritance and Implementation

Variant where both are needed — the capstone that forces you to use extends and implements together because the inner class and the outer interface each contribute something distinct. Starting from the previous Showable with its inner Printable and its own show declaration, consider a scenario where the method is renamed to showOne inside the interface to create a naming gap that separates the two contributions:

interface Showable {
    void showOne(); // interface's own abstract method
    class Printable {
        public void print(){ System.out.println("within print"); }
    }
}
class Trial extends Showable.Printable implements Showable {
    public void showOne() { System.out.println("within showOne"); }
    // print is inherited from Showable.Printable and may be overridden or left as is
}

Now the header uses both extends Showable.Printable (to inherit the inner class Printable and its concrete print()) and implements Showable (to take the interface's contract showOne()). The two keywords sit together: extends first, then implements, exactly the general form class ... extends ... implements ....

• For print, which is a concrete method of the inner class, overriding is optional. Trial inherits print() automatically via extends; it may @Override public void print(){ ... } with its own body if desired, but leaving it out is valid — the inherited body satisfies callers. This is class inheritance behaviour.
• For showOne, which is declared in the interface Showable as public abstract, a definition is compulsory because Trial states implements Showable and showOne is the interface's promise. If you omit showOne, the compiler complains: class Trial should implement the method showOne (or is not abstract and does not override abstract method showOne()). This is interface implementation behaviour.

This reinforces the fundamental divide the lecture hammered: inherited concrete methods may be overridden at will (or left as-inherited); interface-declared methods must be defined or the compiler refuses to compile.

Driver for this combined case:

Trial t = new Trial();
t.showOne(); // → within showOne (compulsory body supplied)
t.print();   // → within print  (inherited, or overridden body if you overrode)

If Trial had also overridden print with its own print, t.print() would dispatch to Trial's override — normal class overriding with polymorphic dispatch.

The professor used this to underscore that extends vs implements is not cosmetic — it predicts which members you get for free and which you must supply. A common exam mistake is to write implements Showable.Printable when Printable is a class — that fails with Printable is not an interface.

21.5.6 Student Questions and Answers

Real-world — Nested interfaces of the form Outer.Inner model scoped contracts — for example, a NetworkService interface exposing an inner Callback or Handler, or a Map interface exposing Map.Entry as a nested interface. The implicit static avoids needing a NetworkService instance just to refer to the callback type, and the public vs private choice lets the outer class hide internal callback contracts.

21.6 Nested Classes — Member Inner and Static Inner Classes

21.6.1 The Nesting Analogy — A Class as a Member of Another Class

A nested class is a class declared inside another class, just as an interface can be nested. Think of the same outer/inner hierarchy you just saw for interfaces, but now both levels are classes. If you have class ABC { class XYZ { } }, then XYZ is an inner class of ABC. The professor's first principle: because XYZ itself is like a member of ABC — similar to a data member or a method — it can directly access whatever members the outer class owns, including private ones. That insider access is the reason nested classes exist.

Mapping the analogy:

• Outer class ABC = house.
• Inner class XYZ = a person who lives in the house and is on the household register (a member).
• Data members of outer = rooms and valuables inside the house.
• Because the person is a member, they have a key to every room — even private rooms.

Where the analogy breaks: a house member still cannot be static-detached from the house without losing that key intimacy — a static nested class (below) is like a registered address that shares the house name but lives elsewhere and keeps no key to private bedrooms.

21.6.2 Types of Nested Classes at a Glance

Use this as a checklist. The next subsections work each type with a full implementation; anonymous and local are deferred to section 21.7 where their one-off and method-scoped nature is isolated.

21.6.3 Member Inner Class — Syntax, Access and Object Creation

Worked example — the canonical illustration the lecture built live:

class Outer {
    private int data = 10;
    class Inner {
        void show() {
            System.out.println(data); // accesses outer's private field
        }
    }
}

Observe: Inner is inside Outer. Its show method accesses data, a private field of Outer. This is not a visibility violation because Inner is like a member of Outer; as a member it can access all data members of its outer, even private ones. The compiler implements this by giving Inner a hidden reference to its enclosing Outer instance (often named Outer.this), and in bytecode it generates synthetic accessor methods — which is why you can even inspect synthetic bridges with javap -p.

General rule: a member inner class can access every outer member — private, protected, default, public, instance or static — as if it were a method of Outer.

Driver class syntax for instantiation — the three-point rule the professor drilled:

Outer o = new Outer();
Outer.Inner in = o.new Inner();
in.show(); // → 10

Outer o1 = new Outer(); // data = 10
Outer o2 = new Outer(); // data = 10 (separate house, same initial value)
Outer.Inner in1 = o1.new Inner(); // tied to o1
Outer.Inner in2 = o2.new Inner(); // tied to o2
in1.show(); // → 10 from o1's data
in2.show(); // → 10 from o2's data
// if Outer had method setData(int v) that changed this.data, each inner would see its own outer's update

21.6.4 Compiler Artifacts and Private-Member Access

When the compiler sees a member inner class, it creates two class files: Outer.class and Outer\\$Inner.class (outer name, dollar sign, inner name, dot class). This file split is how the JVM represents the nesting — there is no "class inside a file" at bytecode level; each is its own .class whose name encodes the nesting with \\$. The companion text T6 Chapter 9 and T2 Chapter 6 both call this out.

You can see it yourself:

javac Outer.java
ls
Outer.class
Outer\\$Inner.class

In a stack trace, frames from inner code appear as Outer\\$Inner.show(Outer.java:6) — the \\$ tells you it was an inner class. In a build directory, the two files are side-by-side; the dollar is not a filesystem quirk but the JVM's canonical encoding.

The instance of the outer must be created first because the inner holds a hidden reference to the outer (the Outer.this pointer). Since the inner has that reference, it can access all data members of the outer, including private ones, as demonstrated above with data. This also explains why a member inner instance keeps its outer alive for garbage collection — the inner cannot be collected while something holds the inner, because the inner transitively holds the outer.

Real-world: This file naming is visible when you inspect build directories and explains why you see \\$ in stack traces for inner classes. Tooling that filters or instruments classes (ProGuard, JaCoCo, coverage reports) must handle \\$ names explicitly; misconfigured filters that ignore \\$ may silently skip inner classes.

Visual — picture a house diagram: a large rectangle Outer containing a field private data = 10 and a smaller rectangle Inner with an arrow Outer.this pointing back to the house's wall. Outside, two .class files are drawn: Outer.class and Outer\\$Inner.class linked by that same \\$ arrow. Below, the construction syntax Outer o = new Outer(); Outer.Inner in = o.new Inner(); is annotated: o births Inner via o.new. X-axis is containment (outer contains inner), y-axis is bytecode split (one source, two class files). Takeaway: one source file, two class files, hidden link enabling private access.

21.6.5 Static Nested Class — Capabilities and Limitations

Add the keyword static to an inner class — it becomes a fundamentally different creature:

class Outer {
    static int sData = 20;
    int iData = 10;
    static class Inner {
        void show() {
            System.out.println(sData);   // ok — static outer field
            // System.out.println(iData); // NOT allowed — no Outer.this
        }
    }
}

Rules — the professor listed them as a compact contract:

• A static nested class is created inside a class and is itself prefixed with static — exactly static class Inner. It is still "nested" (declared inside Outer) but not an "inner" in the family-key sense; it is a type-level member, like a static field.
• It can access static data members of the outer class, including private static members (sData), because statics belong to the type, not to any instance. It accesses them as Outer.sData or directly sData.
• It cannot access non-static (instance) members or instance methods of the outer (iData, private int data, instance void print()), because there is no implicit outer instance attached — there is no Outer.this to look through. Trying System.out.println(iData) gives non-static variable iData cannot be referenced from a static context.
• Only inner classes can be prefixed with static; you cannot write static class Outer at the top level — the language allows static only for members, and an inner class is a member while a top-level class is not (modifier static not allowed here at class level).

Object creation follows the qualified form without needing an outer instance — like a static field access:

Outer.Inner in = new Outer.Inner();
in.show(); // → 20
// No Outer o = new Outer(); needed before

Or, from inside Outer, simply Inner in = new Inner(); since Inner is in scope, but the canonical external form is new Outer.Inner().

Comparison — member inner versus static nested at a glance:

Member inner:     class Outer { class Inner { ... } }
                  Outer o = new Outer();
                  Outer.Inner in = o.new Inner();   // needs o
                  Inner can access outer instance + static

Static nested:    class Outer { static class Inner { ... } }
                  Outer.Inner in = new Outer.Inner(); // no o needed
                  Inner can access only outer static

// Member inner — instance access allowed
class Outer { private int data = 10; class Inner { void show(){ System.out.println(data); } } }
Outer o = new Outer(); Outer.Inner in = o.new Inner(); in.show(); // → 10

// Static nested — instance access forbidden
class Outer2 {
    static int sData = 20; int iData = 10;
    static class Inner { void show(){ System.out.println(sData); } } // ok
    // static class Bad { void show(){ System.out.println(iData); }} // compile error
}
Outer2.Inner in2 = new Outer2.Inner(); in2.show(); // → 20

When to pick which? Use a member inner class when the inner logically needs intimate access to per-object state — classic example: an Iterator inner class that must read the enclosing ArrayList's private elementData and size. Use a static nested class when the helper is logically grouped with Outer for namespace reasons but does not need an outer instance — e.g., Map.Entry (an entry does not need the map instance), or a Builder nested inside the class it builds, or a utility holder that only touches private static configuration.

Real-world — Member inner classes are the idiom for tight coupling such as an ArrayList's Itr iterator that needs private access to its enclosing collection's internal array and count, or a GUI component's inner listener that manipulates the outer panel's private fields. Static nested classes group logically related utilities — Map.Entry, Outer.Builder — that need access only to static configuration without holding an outer instance.

21.7 Anonymous and Local Inner Classes

21.7.1 Anonymous Inner Classes — A Class With No Name

An anonymous inner class (a class with no name) is a class that has no identifier between new and the opening brace {. Because it has no name, you create only a single object of it, typically at the exact point where you need to override a method or implement an interface inline — often as an argument or right-hand side of an assignment.

The syntax the lecture described precisely: it looks like the invocation of a constructor, except that a class definition is contained within the following block in curly braces. You start where a normal new Outer() or new SomeInterface() would go, you append an opening brace {, you supply the method bodies you need, you close the brace }, and you terminate the whole expression with a semicolon ;. The block between the braces is the class body, and it has no name between new and the brace.

Skeleton:

Outer o = new Outer() {
    // anonymous class body: override one or more methods
    void show() { System.out.println("anonymous impl"); }
}; // ← semicolon ends the assignment that contains the class definition

Or with an interface:

Outer o = new Outer() { // Outer is interface
    public void show() { ... }
};

Key characteristics to internalize:

• The name of the actual class created is decided by the compiler; it is anonymous to you as the user, though the compiler assigns an internal synthetic name manifest as EnclosingClass\\$1.class, \\$2, etc., visible in build directories.
• The anonymous class extends the outer class (or implements the interface) and gives an implementation for the declared abstract method(s); the object of the anonymous class is referred to by the variable of the outer type (Outer o) or directly as an argument.
• This is useful when a method or interface is to be overridden or implemented just once and does not warrant a full named subclass in its own file — classic one-off callbacks, GUI listeners, or test doubles.

21.7.2 Worked Example — Anonymous Class Extending an Abstract Class

Setup: An abstract outer class with an abstract method and a concrete method — this is the lecture's first anonymous case, choosing an abstract class as the base to show that the anonymous class can both override the abstract and inherit the concrete:

abstract class Outer {
    abstract void show();
    void print() { System.out.println("within print"); }
}

Anonymous construction in another class Test inside main — the critical line the professor asked you to read character-by-character:

public class Test {
    public static void main(String[] args) {
        Outer o = new Outer() {
            void show() {
                System.out.println("within show of anonymous");
            }
        }; // semicolon terminates the anonymous class expression
        o.show();
        o.print();
    }
}

Reading Outer o = new Outer() { ... };:

• You appear to invoke the constructor of Outer (new Outer()), but because Outer is abstract, you cannot instantiate it bare — new Outer() alone would give Outer is abstract; cannot be instantiated.
• The trailing { void show(){...} } defines an unnamed subclass of Outer that supplies show, and o refers to the single instance of that unnamed subclass. The compiler invents a name like Test\\$1 that extends Outer.
• The anonymous class started at the { after new Outer() and ended at the } before the ;. The ; belongs to the assignment statement, not to the class — forgetting it gives ';' expected.
• Calls o.show() and o.print() both work because o holds a reference to the anonymous subclass which inherits the concrete print method from Outer and supplies show. o.print() → within print (inherited), o.show() → within show of anonymous (overridden).

Outer o = new Outer() {                    // create unnamed subclass of Outer, single instance
    void show(){ System.out.println("within show of anonymous"); }
};                                         // assignment ends

o.show();  // dispatches to anonymous show → within show of anonymous
o.print(); // dispatches to inherited Outer.print → within print

// In the file system:
Outer.class        // abstract base
Test.class         // enclosing class
Test\\$1.class       // anonymous subclass of Outer (synthetic name)

Visual — draw Outer as a dashed abstract box with show() dashed (abstract) and print() solid (concrete). An arrow labelled new Outer(){show()} spawns a small solid unnamed box below it (Test\\$1) containing show solid; a dashed inheritance arrow points back up to Outer and the print box is shown as inherited. A variable arrow o : Outer points to the unnamed box. X-axis is time (definition site), y-axis is type (abstract vs concrete). Takeaway: definition and instantiation happen together at one line.

21.7.3 Worked Example — Anonymous Class Implementing an Interface

The same mechanism works with an interface — just as powerful, with identical syntax, only the base type is interface instead of abstract class. Replace the abstract class with:

interface Outer {
    void show(); // public abstract, implicitly
}

In Test.main — note the public now required on the implementing method because interface methods are public abstract:

public class Test {
    public static void main(String[] args) {
        Outer o = new Outer() {
            public void show() {
                System.out.println("within show of anonymous interface impl");
            }
        }; // anonymous class ends at }, ; ends the assignment
        o.show(); // → within show of anonymous interface impl
    }
}

Again, you create an object of the outer entity (here an interface) and at the same time you define the method inside an anonymous class body that has no name. The class started at { after new Outer() and ended at }, with no name present. The object o can call show via the interface reference, dispatched to the anonymous body.

// Anonymous extending abstract class:
OuterClass o = new OuterClass([args]) {
    // override / implement abstract methods; may call super / access outer
};

// Anonymous implementing interface:
OuterInterface o = new OuterInterface() {
    // implement every abstract method, each must be public
};

A telling detail from the companion text — anonymous is a special case of inner class, and final matters for captured locals. If main has final JTextField textField and the anonymous ActionListener does textField.setText("Hello"), the inner method can access the enclosing variable only because it is final (pre-JDK 8 rule) or effectively final (JDK 8+). The lecture instance used a non-GUI analogue, but the scoping principle is identical.

interface Outer { void show(); }

Outer o1 = new Outer() { public void show(){ System.out.println("first"); } };
Outer o2 = new Outer() { public void show(){ System.out.println("second"); } };
o1.show(); // → first
o2.show(); // → second
// On disk: Test\\$1.class and Test\\$2.class — two distinct synthetic names

21.7.4 Limitations of Anonymous Classes

Three limitations were highlighted — exam-distractor candidates because they discriminate anonymous from named inner classes:

• Synthetic name: The name of the actual class created is decided by the compiler; it is anonymous to you as the user, though the compiler assigns an internal synthetic name manifest as EnclosingClass\\$1.class style (or Outer\\$1.class within a test file). You never write that name in source, but you will see it in .class listings, debugger frames, and coverage reports. The numbering increments with each anonymous declaration in the file.

• Single inheritance and outer-typed reference: The anonymous class extends the outer class (or implements the interface) and gives an implementation for the declared method(s); the object of the anonymous class is referred to by the variable of the outer type (Outer o). This means o is typed as Outer, not as the anonymous type — the anonymous type has no name to declare a variable of that type. Accessing through o sees only what Outer exposes. This is the same hidden-Outer.this and capture semantics as member inner classes, applied inline.

• No additional visible methods: An anonymous class cannot usefully expose additional methods beyond those visible through the outer reference because it is accessed using the reference to the outer type. If you add a fresh method void extra(){ System.out.println("extra"); } inside the anonymous body, you cannot call o.extra() because the static type of o is Outer, which knows nothing about extra. The compiler checks the declared type of o, not the runtime synthetic type. The extra method exists inside the synthetic class but is unreachable through Outer — it is essentially dead unless called internally or via reflection.

Outer o = new Outer() {
    void show(){ System.out.println("show"); }
    void extra(){ System.out.println("extra"); } // exists, but...
};
o.show();  // ok — Outer declares show
// o.extra(); // compile error: cannot find symbol: method extra()

Consequence: anonymous classes are limited to overriding or implementing what the outer type already declares — they cannot extend the API visible through o. If you need an extra method to be callable from outside, use a named inner or top-level class with its own type.

A fourth implicit limitation the professor noted in passing: anonymous classes cannot have an explicit named constructor — they have no name to write one with. You can only supply an instance initializer { ... } or call the superclass constructor arguments inside new Outer(args), but not public Anonymous(){...}.

21.7.5 Local Inner Classes — Classes Inside Methods

Illustration — the lecture's minimal trace:

class Outer {
    void outerMethod() {
        class Inner {
            void show() { System.out.println("inside local inner"); }
        }
        Inner i = new Inner(); // must be inside the same method
        i.show();              // → inside local inner
    }
}

So you have Outer, its method outerMethod, and inside that method you declare class Inner — no public, no Outer. qualifier needed, just class Inner. Object creation new Inner() and the call i.show() must occur within the same method scope; you cannot create Inner outside outerMethod because the type is invisible there — cannot find symbol: class Inner if you try new Inner() in main.

When you create an object of Outer and call outerMethod(), that method instantiates its own local Inner and exercises it:

Outer o = new Outer();
o.outerMethod(); // → inside local inner

You cannot directly call the inner's method via an outer object without going through the enclosing method, because again the inner type is lexically confined to the method. The path Outer o = new Outer(); Outer.Inner in = ... does not work — Inner is not Outer.Inner; it is only Inner within outerMethod's block.

Rules the professor stressed alongside local inners:

• A local inner class may access outer class instance fields and methods (via Outer.this) and static members, plus final / effectively-final locals and parameters of the enclosing method. It cannot access a non-final mutable local that changes afterwards (the same capture rule as anonymous classes, rooted in the compiler copying values).
• It cannot have public/private/protected before class Inner — local classes are like local variables, they have no access modifier.
• It cannot be static as static class Inner inside a method — local classes are inherently tied to the method activation, not to the type.
• Compiled form: Outer\\$1Inner.class or Outer\\$1\\$Inner.class depending on nesting — another \\$ on disk, but now numbered by method scope. The file artifacts are part of what the exam flagged as "know the dollar naming".

Comparison — local vs anonymous vs member:

Member inner:   class Outer { class Inner { void show(){} } }     // in class scope, needs o.new
Anonymous:      Outer o = new Outer(){ void show(){} };            // no name, one object, at new
Local:          void outerMethod(){ class Inner{ void show(){} }   // in method scope, new only there
                    Inner i = new Inner(); i.show(); }
Static nested:  class Outer { static class Inner{} }               // type member, no Outer.this

Visual — draw Outer as an outer rectangle, outerMethod() as a smaller rounded rectangle inside it, Inner drawn inside that rounded rectangle with arrows pointing only within it. An arrow from main trying to new Inner() from outside the rounded rectangle is blocked by a wall labelled "scope = method braces". Takeaway: Inner lives and dies within outerMethod's { }.

Real-world — Anonymous inner classes for one-off overrides were the idiom for event listeners and callbacks before lambdas — button.addActionListener(new ActionListener(){ public void actionPerformed(...){...}}) and Collections.sort(list, new Comparator<Country>(){...}). Local inner classes reduce namespace pollution when a method needs a small helper (a validator, a parser state) that should never be exposed to the rest of the class.

21.8 Exception Handling — Fundamentals and the Try-Catch-Finally Model

21.8.1 What an Exception Is — Compile-Time vs Runtime Errors

When you run a program you may experience errors. The professor organized them into two broad categories that predict who is responsible for finding them.

• Compile-time errors (checked by the compiler before execution, also called static errors) — the compiler discovers these before any line runs. Examples the lecture used: missing semicolon, misspelling an identifier (prtinln for println), using a variable without declaration, or mismatched types in an assignment that the compiler can prove wrong. You discover these immediately when you compile; the program refuses to run — javac reports the file and line and you fix it. No runtime behaviour is involved.

• Runtime errors (not detected at compile time, also called dynamic errors) — the compiler cannot know at compile time that a user will supply 0 as a divisor, or 12 elements for a size-10 array, or a string "hello" where Integer.parseInt expects digits, or that the console will fail to respond to readLine. These errors surface only while the program runs and may cause abnormal termination — the method stops abruptly, a default stack trace prints, and no user-friendly explanation appears. This runtime failure situation is what is called an exception (an object that represents an abnormal condition at runtime).

Simple rule to separate them: Ask "Does the compiler have enough information without running the program and without reading runtime input?" If yes, it is compile-time. If the fault depends on runtime data (user input, file existence, array length at execution, arithmetic divisor value), it is an exception.

21.8.2 Why Abnormal Termination Must Be Avoided

If a runtime error occurs, the program's default behaviour is to terminate abnormally inside the method where the fault happened, unwind the call stack, print a raw stack trace (class, method, file, line number), and stop — with no explanation tailored for the user. That trace is useful for debugging but bewildering for an end user.

Exception handling is about making the user aware of the problem in a controlled way and keeping the system in a defined state. Instead of vanishing with Exception in thread "main" java.lang.ArithmeticException: / by zero at Exc0.main..., the program should print a clear message that some exception has occurred (division by 0), handle it gracefully (perhaps retry, perhaps return a safe default), and continue or exit cleanly without an abrupt crash. The entire try-catch-finally-throw-throws apparatus serves this single goal: convert an uncontrolled crash into a controlled, user-visible handling path.

21.8.3 The Try Block — Guarding Risky Statements

The statements for which you know an exception may occur you write inside a try block. The verbal description preserved from the lecture: put the division c = a / b; inside try { ... } because division may generate an exception if b is zero. A method can have nested or multiple try blocks; nesting — a try inside a try — is permitted and is illustrated in section 21.9.6.

int a, b, c;
a = 10; b = 0; // b will be read from user in the general case; compiler cannot know it is 0
try {
    c = a / b; // this may generate ArithmeticException at runtime
    System.out.println("result " + c); // skipped if exception thrown
} catch (ArithmeticException e) {
    // handler (next subsection)
}

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
try {
    String s = br.readLine(); // may throw IOException (checked)
}

Important execution flow: Once an exception is thrown inside try, the remaining statements inside that try are not executed — control jumps immediately to the matching catch. So System.out.println("This will not be printed.") after int d = 42 / b; inside try is skipped when b == 0.

The lecture's mathematical note: for integers, division by zero is undefined and the JVM defines it to throw ArithmeticException. For floating-point double division, a / 0.0 would yield Infinity per IEEE 754 and not throw — a distinction that sometimes appears as a boundary-condition pitfall.

Visual — picture a highway with a dashed construction zone labelled try { risky statements }. A guard rail catch runs alongside. Cars (control flow) travel normally through the zone; when a red exception flag pops up on a statement (a / b with b=0), the car swerves instantly over the guard rail into the adjacent catch lane, skipping the remaining zone. X-axis is program time (statement order), y-axis is execution path (normal vs handling). Takeaway: try encloses risk; an exception exits the try at the exact failing statement.

21.8.4 The Catch Block — Receiving and Handling the Thrown Exception

Every try should be followed by at least one catch block. A catch receives an argument describing the exception type — just like a method parameter — and its block contains the handling code. It is conditional — it works only when an exception is present; if no exception is generated inside try, the catch is skipped entirely and execution continues after the try-catch.

int a = 10, b = 0, c;
try {
    c = a / b; // may throw ArithmeticException
    System.out.println("no exception path");
} catch (ArithmeticException e) {
    System.out.println("division by 0"); // e is the thrown object
}
System.out.println("after catch"); // always reached unless handler rethrows

catch receives an argument of Exception or its derived class, matching the exception the try threw. The parameter ArithmeticException e names the throwable object so the handler can inspect it (e, e.getMessage(), e.printStackTrace()), or just ignore details and print a fixed message.

You can have multiple catches for one try, which behave like case labels in a switch, each targeting a different exception class — ordered most-specific first (see section 21.9.5):

try {
    c = a / b; // this may generate ArithmeticException
    String s = br.readLine(); // or IOException
} catch (ArithmeticException e) {
    System.out.println("division by 0");
} catch (IOException e) {
    System.out.println("input output exception generated");
} catch (Exception e) {
    System.out.println("some other exception");
}
System.out.println("after catch");

If a / b throws ArithmeticException (say $b=0$ with integer division), the first catch (ArithmeticException e) matches (exact type), prints division by 0, and the program avoids abnormal termination, proceeding to after catch. The second catch (IOException e) and third catch (Exception e) are bypassed — first match wins, like switch fallthrough without fall.

The second catch (Exception e) is broader — it would handle other Exception-based types if they arose — for instance, if inputs were not initialized and the user typed a non-numeric string where Integer.parseInt was called, a NumberFormatException could appear; or if an array of size 10 received 12 values via a[12], an ArrayIndexOutOfBoundsException could appear. Each fault has its own appropriate catch class (see the multiple-catch example where all three are demonstrated).

Crucial control-flow fact: a catch does not "return to" the try. Once jumped to catch, remaining try statements are not replayed; after handling, execution continues after the whole try-catch-finally construct.

int a = 10, b = 0, c;
try {
    c = a / b;                              // throws ArithmeticException: / by zero
    System.out.println("This will not be printed.");
} catch (ArithmeticException e) {
    System.out.println("division by 0");    // prints
} catch (Exception e) {
    System.out.println("some other exception");
}
System.out.println("after catch");          // prints — program survived

// Without the catch, the default handler would have printed:
// Exception in thread "main" java.lang.ArithmeticException: / by zero
//    at Exc0.main(Exc0.java:4)

21.8.5 The Finally Block — Unconditional Execution

The third construct is finally. There can be only one finally associated with a try-catch sequence, and it does not receive an exception argument. It is unconditional: whether there is an exception or not, whether a catch handled it or an exception slipped through, the statements inside finally always execute — on the way out of the try-catch, before the method returns or propagates.

try {
    // risky statements: c = a / b; String s = br.readLine(); s = a[2];
} catch (ArithmeticException e) {
    System.out.println("division by 0");
} catch (IOException e) {
    System.out.println("IOException generated");
} finally {
    // always runs — close resources, print completion note, etc.
    System.out.println("finally always executes");
}

Typical use: cleanup that must happen regardless — closing a file handle, releasing a lock, flushing a buffer, printing a procC's finally completion trace as in the reference example.

try {
    br = new BufferedReader(new InputStreamReader(System.in));
    String s = br.readLine();
} catch (IOException e) {
    System.out.println("IOException generated");
} finally {
    if (br != null) br.close(); // always close, success or failure
}

A question answered in the source: Is finally optional? Inclusion of finally in your program is optional — it is your choice whether to write it. But if you do include it, it will always execute. It is not conditional like catch, which runs only when its exception type appears. You may have try-catch-finally, try-catch without finally, or try-finally without catch (mainly for cleanup when you intend to let the exception propagate).

Important subtlety the reference flags: If a finally block appears, it executes even when the try exits via return or via an uncaught exception — just before the method returns. And each try needs at least one catch or one finally — a bare try { ... } alone does not compile.

Visual — picture three doors in sequence: try → catch (conditional door) → finally (unconditional door). Two balls are drawn: one labelled "no exception" that rolls straight through try, skips the catch door, and exits through finally; one labelled "exception" that bounces off try into catch, then both balls converge and must exit through the same finally door, whose sign reads "always". Takeaway: catch is conditional; finally is unconditional.

21.8.6 Throw vs Throws — Generating vs Forwarding

Two more statements complete the four-keyword picture (try, catch, finally plus this pair). Their names differ by one letter but roles are opposite.

• throw is used to generate an exception at the point where you detect a fault. You write throw new InvalidBoxDimensionException(length); to create a new exception object and immediately throw it — control leaves that point and seeks a matching catch up the call stack. This clause can only be used with objects of throwable type (throw new String("hi") would not compile).

if (l <= 0) throw new InvalidBoxDimensionException(l);

• throws is used to forward (declare) an exception on a method/constructor header. You annotate the header with throws IOException or throws InvalidBoxDimensionException to say: if any exception of this type is generated while this method executes and is not caught locally, forward it to the caller — declare who should handle it. You are not handling it locally; you are declaring the handling obligation upward. This is the handle-or-specify contract for checked exceptions.

void read() throws IOException {
    String s = br.readLine(); // readLine declares throws IOException — caller must handle or re-throws
}
Box(int l, int w, int h) throws InvalidBoxDimensionException {
    if (l <= 0) throw new InvalidBoxDimensionException(l);
}

Example contrast from the BufferedReader discussion that the professor returned to twice:

// Strategy 1 — forward with throws (let caller handle)
void input() throws IOException {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    String s = br.readLine(); // if IOException fired, it is forwarded to IOException handler
}

// Strategy 2 — handle locally with try-catch (handle here)
void input() {
    try {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String s = br.readLine();
    } catch (IOException e) {
        System.out.println("input output exception generated");
    }
}

These are two equivalent ways to satisfy the checked-exception contract for IOException: handle it now with try-catch, or specify that someone else will handle it with throws on the method header and let the exception propagate — as seen in class ThrowsDemo { static void throwOne() throws IllegalAccessException { throw new IllegalAccessException("demo"); } } where main then catches it.

if (w <= 0) throw new InvalidBoxDimensionException(w);
// w = 0 triggers w ≤ 0, new object InvalidBoxDimensionException(0) created, stack jumps to nearest
// catch (InvalidBoxDimensionException e)

if (b == 0) throw new ArithmeticException("/ by zero");
c = a / b;

Common pitfall flipped: Writing throws new InvalidBoxDimensionException(l); on a header (merging the two) does not compile — throws lists a type, not an instantiation. Correct split is Box(...) throws InvalidBoxDimensionException { ... throw new InvalidBoxDimensionException(l); }.

Real-world — This try-catch-finally-throw-throws pattern underpins production error handling: BufferedReader.readLine() and Files.readAllLines force checked IOException handling; arithmetic and indexing faults are naturally caught as unchecked; the finally block still appears in resource handling (file close, connection close, lock unlock) where cleanup must be guaranteed whether the try succeeded or threw, even though modern try-with-resources often supersedes manual finally for Closeable resources.

21.9 Exception Hierarchy, Checked vs Unchecked and Multiple and Nested Handling

21.9.1 The Throwable Hierarchy — Throwable, Exception and Error

Java organizes throwables as an inheritance hierarchy with a single root. At the root is Throwable, an inbuilt class that extends Object and provides the stack-trace machinery (printStackTrace(), getMessage(), getCause()). Throwable has two direct subclasses that partition all throwables into two distinct branches — the standard diagram the lecture referenced and reproduced from T6 Chapter 10:

• Exception — the root of all exceptions that a programmer can and should handle under normal circumstances. As a user you can catch runtime faults, I/O faults, and other handleable conditions; they all belong to Exception or one of its subclasses. Creating your own custom exception means subclassing Exception (or RuntimeException — see below).
• Error — exceptions that are not to be caught under normal circumstances, even though technically you could write catch (Error e). You as a user cannot sensibly handle high-level errors that belong to Error — they model virtual-machine or environment failures such as StackOverflowError, OutOfMemoryError, VirtualMachineError, or LinkageError. They are present in the hierarchy but are not the focus of ordinary try-catch.

Under Exception, several subclasses branch further, each refining the fault family:

Throwable
├── Error (unchecked, not normally caught — VM failures)
│   └── StackOverflowError, OutOfMemoryError, ...
└── Exception (handleable)
    ├── IOException (I/O faults — checked)
    │   └── FileNotFoundException, ...
    ├── InterruptedException, ClassNotFoundException, ... (checked)
    └── RuntimeException (unchecked — runtime faults)
        ├── NullPointerException
        ├── ArithmeticException (e.g. divide by zero)
        ├── ArrayIndexOutOfBoundsException (≈ IndexOutOfBoundsException branch)
        ├── ClassCastException
        ├── NumberFormatException
        ├── IllegalArgumentException, ...
        └── ...

Notes the professor emphasized:

• The picture Throwable at top, splitting into Exception and Error, with Exception splitting into IOException and RuntimeException, and RuntimeException splitting into the arithmetic/null-pointer/cast families, is the diagram to reproduce on the exam. Labelling each level with one example suffices.
• Error and Exception are both subclasses of Throwable; Error is-not a subclass of Exception. Error and Exception are siblings, not parent-child.
• Exception is checked, Error is unchecked, RuntimeException (a subclass of Exception) is unchecked — the checked vs unchecked split cuts within Exception, with Error on a separate unchecked branch.

21.9.2 Checked Exceptions — Compile-Time Checking and the Throws Contract

Checked exceptions are those checked at compile time — the compiler enforces handling. Formally, any subclass of Exception except RuntimeException and its descendants, and except Error, is checked. Equivalently: the set Exception \ (RuntimeException subtree ∪ Error subtree) is checked. IOException is the canonical canonical example the lecture returned to.

Rule: If a method throws any checked exception — either by explicitly throw new IOException(...) or by calling a method that declares throws IOException (such as BufferedReader.readLine()) — then the method has to handle the exception itself (wrap the risky statement in try-catch for IOException), or it must specify the exception using a throws clause on its header so the caller handles it. The compiler enforces this contract; the burden is static.

void input() throws IOException {               // specify
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    String s = br.readLine(); // readLine declares throws IOException — caller must handle or specify
}

If you write bare String s = br.readLine(); without try-catch(IOException) and without throws IOException on the enclosing method, the compiler stops with error: unreported exception java.io.IOException must be caught or declared to be thrown and points to that line as culprit. This demonstrates that checked exceptions are indeed checked by the compiler: the problematic statement must be kept within try-catch or the method must declare throws.

The design rationale the professor borrowed from the companion text: checked exceptions model recoverable faults the caller can reasonably be expected to plan for — missing file, broken network, console failure — so the API contract forces the call site to acknowledge them. readLine returning a line from the console is exactly that: the console may fail at input time.

Checked vs throws contract choices per method:

• Handle locally: try { s = br.readLine(); } catch (IOException e){ System.out.println("input output exception generated"); } — the method is self-contained.
• Forward: void input() throws IOException { s = br.readLine(); } — the method declares throws and each caller must in turn handle or forward until some try-catch eventually appears in the chain; if no one catches, the default handler prints the stack trace.

The lecture used static void throwOne() throws IllegalAccessException { throw new IllegalAccessException("demo"); } and static void compute(int a) throws MyException { if (a>10) throw new MyException(a); } as checked-throw prototypes where throws on the header is compulsory — delete it and compilation fails.

21.9.3 Unchecked Exceptions — Runtime Subclasses

Unchecked exceptions are those not checked at compile time; they are automatically defined for programs and the compiler never forces you to write throws for them. Formally, any subclass of RuntimeException (and any Error) is unchecked.

Any subclass of RuntimeException is by default unchecked — the compiler does not force you to write a throws declaration for them, though you may still catch them if you wish. Similarly, Error subclasses are unchecked and are normally permitted to propagate to the default handler.

Examples the lecture listed — keep this list for multiple-catch discrimination:

• ArithmeticException — integer division by zero (c = a / b with $b=0$, or a/(a-a)).
• ArrayIndexOutOfBoundsException — accessing a third element of a two-element array (int a[] = {5,10}; int x = a[2]; where valid indices are 0 and 1).
• ClassCastException — casting an object to an incompatible type.
• NumberFormatException (a subclass of IllegalArgumentException) — type-casting a non-numeric string, e.g. Integer.parseInt("hello") or the lecture's "casting a string to an int" naming.
• NullPointerException — dereferencing null (String s = null; s.length();).

These all arise at runtime and the compiler does not force you to write throws ArithmeticException etc. You may write catch (ArithmeticException e) voluntarily to survive the fault (Division by zero. and a = 0; continue in the HandleError loop), but omitting it is not a compile error.

Real-world illustration the professor drew from the distinction: The reason network/file/console code is forced to handle IOException (checked — declared on readLine, FileReader, Socket APIs) while a pure arithmetic slip a / b or indexing a[2] is caught only where you choose to guard it is exactly the checked/unchecked divide. Production code often wraps the unchecked NumberFormatException from parseInt with its own catch to report "invalid input, expected a number", while throws IOException on the method is demanded by the compiler for any readLine path that is not caught.

checked:    Exception \ RuntimeException subtree  (must try-catch or throws)
unchecked:  RuntimeException subtree ∪ Error       (may catch, never must throws)

21.9.4 Worked Example — BufferedReader and the Compulsory Handling of IOException

Scenario — taking console input via BufferedReader and System.in with readLine, the textbook example that makes the checked contract concrete:

BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String s = br.readLine(); // problem line if written bare — readLine declares throws IOException

Why readLine throws IOException: it reads from a stream that may fail — console not responding, pipe broken, input unavailable at input time, or an IOException wrapped from the underlying Reader. The method signature is public String readLine() throws IOException, so the type IOException (a checked Exception subclass outside RuntimeException) forces the call site obligation.

Two handling methods were presented — handle-or-specify, choose one:

Method 1 — Forward with throws on the method header (pass the obligation to the caller):

void input() throws IOException {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    String s = br.readLine(); // if exception during execution, it is forwarded to IOException handler higher up
}

Line by line: void input() throws IOException declares the type that may escape; the caller of input() must in turn either try-catch(IOException) around input() or itself declare throws IOException, propagating until some catch appears. If no handler ever catches, the default handler prints the IOException stack trace.

Method 2 — Handle with try-catch locally (absorb the obligation here):

void input() {
    try {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        String s = br.readLine();
    } catch (IOException e) {
        System.out.println("input output exception generated");
        // e.getMessage() / e.printStackTrace() available if you want details
    }
}

Here the try guards the readLine statement; on IOException the catch prints input output exception generated and the program continues without the caller ever knowing an IOException happened. This is the "handle it yourself" branch.

Bare method — compilation error if neither is done — the lecture reproduced the message verbatim:

void input() {
    BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
    String s = br.readLine(); // bare, no try, no throws on method
}
error: unreported exception java.io.IOException must be caught or declared to be thrown
    String s = br.readLine();
                 ^

The caret points to the readLine() call as the culprit. This demonstrates that checked exceptions are indeed checked by the compiler: the problematic statement must be kept within try-catch or the method must declare throws. Swapping the example to int c = a / b; with no try would not produce a similar error — ArithmeticException is unchecked, so bare division compiles silently, even though it may throw at runtime.

class OK1 { void m() throws IOException { new BufferedReader(...).readLine(); } } // ok — forward
class OK2 { void m() { try { new BufferedReader(...).readLine(); } catch(IOException e){} } } // ok — handle
class Bad { void m() { new BufferedReader(...).readLine(); } } // error: unreported exception must be caught or declared
class AlsoOK { void m() { int c = 10/0; } } // ok even without catch — ArithmeticException is unchecked (but will throw at runtime)

21.9.5 Multiple Catch Blocks for a Single Try

A try block may contain multiple statements, each capable of throwing a different exception category. Therefore one try may be capable of throwing multiple distinct types, and you should catch all expected types with one catch per type — the general pattern the lecture modelled on switch cases selected by the runtime type of the throwable.

Worked example exceptionDemoTest — this is the lecture's integrated fault-mix, deliberately combining three fault families in one scope:

Setup: int a[] = {5, 10}; a two-element integer array with valid indices 0 and 1; the try will mix arithmetic, array indexing, and String → int type conversion.

try {
    int b = ...; // e.g. int divisor = Integer.parseInt(s); or int k = a[0]/0;
    int x = ...; // conceptually: Integer.parseInt-style cast plus division using array indices
    System.out.println(x);
} catch ... // see below

This try mixes:

• Arithmetic (x = a[0] / b where b may be 0 → ArithmeticException).
• Array indexing (a[2] where only a[0] and a[1] exist → ArrayIndexOutOfBoundsException).
• Type conversion (Integer.parseInt(s) where s may be "hello" → NumberFormatException).

Catches — one per type, like cases in a switch, each targeting the class whose condition failed:

catch (ArithmeticException e) {
    System.out.println("arithmetic exception — division by zero etc.");
}
catch (NumberFormatException e) {
    System.out.println("number-format exception — type-casting mismatch, e.g. non-numeric string to int");
}
catch (ArrayIndexOutOfBoundsException e) {
    System.out.println("array-index-out-of-bounds — attempted access beyond size 2");
}

try { ... }
catch (ArithmeticException e) { ... }
catch (ArrayIndexOutOfBoundsException e) { ... }
catch (Exception e) { ... } // broader last

Each catch targets one exception class. If the try throws ArithmeticException (divisor 0), the first catch matches; if it throws NumberFormatException (parsing "abc"), the second matches; if a[2] is accessed with only a[0] and a[1] present, the third matches. This is the general pattern: one try, many catch statements like cases in a switch on runtime type.

int a[] = {5, 10};
try {
    int divisor = 0;
    int x = a[0] / divisor;   // → ArithmeticException: / by zero   → catch 1
    // Suppose divisor was non-zero but next line ran:
    int v = Integer.parseInt("hello"); // → NumberFormatException → catch 2
    System.out.println(a[2]);         // → ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2 → catch 3
} catch (ArithmeticException e) {
    System.out.println("arithmetic — " + e);
} catch (NumberFormatException e) {
    System.out.println("number-format — " + e);
} catch (ArrayIndexOutOfBoundsException e) {
    System.out.println("index out-of-bounds — " + e);
}
System.out.println("after try-catch blocks."); // always continues after handling

// With args.length trick (MultipleCatches):
// java MultipleCatches           → a=0 → 42/0 → ArithmeticException → divide by 0 path
// java MultipleCatches TestArg   → a=1 → c[42] with c length 1 → ArrayIndexOutOfBoundsException → array index oob path

Exam note precisely as phrased: Expect questions asking you to associate a specific line with its appropriate catch class among ArithmeticException, NumberFormatException, and ArrayIndexOutOfBoundsException. The three-way split above is the answer template — arithmetic → ArithmeticException, string-to-int conversion → NumberFormatException, illegal index → ArrayIndexOutOfBoundsException.

Visual — picture a funnel try with three coloured exit tunnels labelled ArithmeticException, NumberFormatException, ArrayIndexOutOfBoundsException. A throwable ball falls into the funnel and the trapdoor whose label matches the ball's runtime type opens — like a switch on instanceof. X-axis is exception type, y-axis is handler order (specific before broad). Takeaway: one try can throw many types; each catch is a typed trapdoor; first match wins.

21.9.6 Nested Try and Catch Blocks

You can have a try inside a try, with catches at different lexical levels. Nesting can be explicit (braces inside braces) or via a method call where the called method itself contains a try — in both cases the inner try's lifetime is nested inside the outer's lifetime.

Layout 1 — inner try with its own catch, outer try with its own catch:

try {
    // outer statements
    int a = args.length;
    int b = 42 / a; // ArithmeticException if a==0 — handled by outer catch
    try {
        // inner statements
        if (a==1) a = a/(a-a); // ArithmeticException if a==1 — would need inner catch or propagates
        if (a==2) {
            int c[] = {1};
            c[42] = 99; // ArrayIndexOutOfBoundsException if a==2 — caught by inner
        }
    } catch (ArrayIndexOutOfBoundsException e) {
        System.out.println("Array index out-of-bounds: " + e);
    }
} catch (ArithmeticException e) {
    System.out.println("Divide by 0: " + e);
}

Layout 2 — outer try, inner try, statements, and then associated catches together at the same level — both nestings are permitted; your program will not complain if you nest them in different valid arrangements, because the compiler cares only that each try has a matching catch or finally in scope.

The principle is lexical scoping plus stack unwinding: an inner catch handles faults thrown from its inner try first; if no inner catch matches, the throwable propagates and the next enclosing catch is consulted; this continues until one succeeds or the chain reaches the default handler. Inner handlers therefore handle narrowly; outer handlers are the backstop.

Concrete sample runs from T6's NestTry that the lecture reused:

java NestTry            // a = 0 → outer 42 / 0 → "Divide by 0: java.lang.ArithmeticException: / by zero"
java NestTry One        // a = 1 → a==1 → a/(a-a) = 1/0 → inner throws Arithmetic, inner only catches IndexOutOfBounds → propagates to outer → "Divide by 0: ..."
java NestTry One Two    // a = 2 → a==2 → c[42]=99 in inner → "Array index out-of-bounds: java.lang.ArrayIndexOutOfBoundsException: 42"

The call-stack nesting variant MethNestTry shows the same propagation through a method: try { int a = args.length; int b = 42/a; nestTry(a); } catch(Array...) where nestTry(int a) itself has an inner try-catch(ArrayIndexOutOfBounds) — the method call is implicitly a second nesting level.

21.9.7 Student Questions and Answers

Real-world — Fault-tolerant production code mirrors the two-branch hierarchy: checked IOException from BufferedReader.readLine() is handled by try-catch or forwarded via throws IOException, while unchecked ArithmeticException, ArrayIndexOutOfBoundsException, NumberFormatException, NullPointerException are caught reactively where arithmetic or indexing is risky. Nested and multiple-catch patterns and finally blocks appear in resource handling where outer try-catch scopes separate I/O faults from business-logic faults.

21.10 User-Defined Exceptions with Throw and Throws

21.10.1 Creating Your Own Exception by Extending Exception or RuntimeException

A programmer can write either a checked or an unchecked custom exception by extending the appropriate root class with extends. You use exactly the same extends keyword as for any class hierarchy; the type system then treats your new class as an exception and the five-keyword machinery (try-catch-throw-throws-finally) applies to it unchanged.

Checked (must handle or throws):   class MyChecked extends Exception { }
                                  class MyIOChecked extends IOException { }

Unchecked (may catch, never must): class MyUnchecked extends RuntimeException { }
                                  class InvalidBoxDimensionException extends RuntimeException { } // lecture

Two practical design guidelines the professor emphasized:

• Choose the root by intent: Is the fault a programming error that callers can hardly anticipate or locally recover from (invalid dimensions, illegal argument)? Make it unchecked (extends RuntimeException) so you fail fast without burdening every call site — this is the InvalidBoxDimensionException choice. Is the fault a recoverable condition callers should plan for (missing configuration file, unavailable service)? Make it checked (extends Exception) so the compiler forces acknowledgement.
• Error is not the right root for domain exceptions — reserve Error for VM failures. Domain rules belong under Exception or RuntimeException.

The lecture's tiny example MyException extends Exception { private int detail; MyException(int a){ detail=a; } public String toString(){return "MyException["+detail+"]";}} with static void compute(int a) throws MyException { if(a>10) throw new MyException(a); } is the checked counterpart to the unchecked InvalidBoxDimensionException that follows.

21.10.2 Worked Example — InvalidBoxDimensionException and the Box Class

Purpose: Define an unchecked exception InvalidBoxDimensionException that is thrown whenever an attempt is made to create a Box instance whose length, width, or height is less than or equal to $0$. The verbal description the professor preserved: for a box, if any of the three dimensions is $\le 0$, the instance is invalid and an exception should be generated carrying the faulty dimension, rather than silently storing a degenerate box.

Step 1 — The exception class itself:

class InvalidBoxDimensionException extends RuntimeException {
    InvalidBoxDimensionException(int dim) {
        System.out.println("box instance with invalid dimension: " + dim);
        // optionally: super("invalid dimension: " + dim);
    }
}

Because it extends RuntimeException, it is unchecked — callers are not forced by the compiler to handle it, though the lecture's driver chooses to. The constructor prints a diagnostic line with the invalid dimension passed as argument, so instantiation itself logs the fault. In production you would often call super(String.valueOf(dim)) or super("invalid dimension: " + dim) to let Throwable.getMessage() carry the detail and let printStackTrace render it; the lecture's print-based form is the minimal visible-effect version. This is the definition of the user-defined exception class — its mere existence in the type system makes catch (InvalidBoxDimensionException e) legal.

Step 2 — The Box class that uses it:

class Box {
    int length, width, height;
    Box(int l, int w, int h) throws InvalidBoxDimensionException {
        if (l <= 0) throw new InvalidBoxDimensionException(l);
        if (w <= 0) throw new InvalidBoxDimensionException(w);
        if (h <= 0) throw new InvalidBoxDimensionException(h);
        // all dimensions valid
        this.length = l; this.width = w; this.height = h;
        // surface area of a rectangular cuboid — total area of all six faces:
        // area = 2*(l*w + w*h + h*l)
    }
    int area() {
        return 2 * (length * width + width * height + height * length);
        // = 2lw + 2wh + 2hl
    }
}

Key points line by line:

• Class header class Box { int length, width, height; ... } stores the three dimensions as instance state.
• Constructor header Box(int l, int w, int h) throws InvalidBoxDimensionException — this throws clause lists the exception type that may escape the constructor. Because InvalidBoxDimensionException is unchecked, this throws is not required by the compiler; it is included as explicit documentation and as the lecture's idiom that "forward to that exception class to handle." For the checked variant MyException extends Exception, the same throws MyException would be compulsory.
• Inside, each dimension is checked with if (dim <= 0) throw new InvalidBoxDimensionException(dim); — the throw keyword explicitly creates a new throwable instance at the failing branch and immediately exits that branch's normal flow. The ordering matters: l checked first, then w, then h; the first failing dimension throws, the later checks are skipped, so the reported dim identifies which dimension failed.

Domain checks on the formula:

• Dimensional: $lw$, $wh$, $hl$ each have dimension $(\text{length}{)}^2$, so their sum has area dimension, and multiplying by $2$ stays area — consistent.
• Boundary: If $l,w,h\to 0^{+}$, area $\to 0^{+}$, which matches a vanishing box. If one dimension fails (\le 0), the exception prevents the nonsensical case where a "negative area" would be computed.
• Spot-check: $l=w=h=1$ (unit cube) → area $=2(1+1+1)=6$ — correct, six unit squares.

21.10.3 Worked Example — Driver Code with Try and Catch for Two Invalid Boxes

Driver class main must guard the construction because the dimensions may be invalid — the Box constructor may throw. The lecture worked this as two separate try-catch blocks, each isolating one risky construction, so that the second try still runs even if the first threw.

First invalid instance — width zero (the middle dimension fails):

try {
    Box b1 = new Box(5, 0, 10); // l=5 ok, w=0 triggers w ≤ 0, h=10 not yet tested
} catch (InvalidBoxDimensionException e) {
    System.out.println("invalid width"); // or other diagnostic / handling; e already logged at throw site
}

Tracing: Box(5,0,10) enters constructor, if (l <= 0) with $l=5$ is false, so next line checks if (w <= 0) with $w=0$ — because $0\le 0$ is true, throw new InvalidBoxDimensionException(0) creates the exception object (which prints box instance with invalid dimension: 0 from the exception's constructor) and abruptly exits the Box constructor. The call new Box(5,0,10) was inside try, so control jumps to the matching catch (InvalidBoxDimensionException e) which receives that generated throwable into e and prints the handling text invalid width. The program does not abnormally terminate; b1 was never fully initialised and should not be used after the exception.

Execution order for this block: constructor entry → l check pass → w check fail → new InvalidBoxDimensionException(0) → exception constructor print → throw → catch print invalid width → continue after catch.

Second invalid instance — height zero (the last dimension fails):

try {
    Box b2 = new Box(5, 10, 0); // l=5 ok, w=10 ok, h=0 triggers h ≤ 0
} catch (InvalidBoxDimensionException e) {
    System.out.println("invalid height / dimension");
}

Same flow with h instead of w: l=5 and w=10 both pass their >0 checks, h=0 satisfies $h\le 0$, so throw new InvalidBoxDimensionException(0) fires, the exception constructor prints box instance with invalid dimension: 0, and the catch prints invalid height / dimension.

Each risky statement is kept within its own try and each has a catch capable of catching InvalidBoxDimensionException objects. A matching catch must create a variable (e.g., e) to receive the throwable and then execute handling code such as System.out.println. Wrapping each new Box(...) separately (rather than try { new Box(5,0,10); new Box(5,10,0); } catch...) matters: a single try with two constructions would skip the second construction if the first threw, because control jumps at the first throw and remaining try statements are skipped.

// First block:
Box b1 = new Box(5, 0, 10);
→ box instance with invalid dimension: 0   (from InvalidBoxDimensionException constructor)
→ invalid width                          (from catch)

 // Second block (always runs — separate try):
Box b2 = new Box(5, 10, 0);
→ box instance with invalid dimension: 0
→ invalid height / dimension

// If both had been valid:
Box b3 = new Box(5, 10, 7);
// no exception; area() → 310 as computed above
System.out.println("valid box area = " + b3.area()); // → 310

A third valid case is the positive control the lecture left implicit: when all three dimensions are positive, no throw fires, the fields initialize, and area() evaluates the formula above — you should test with $l=5,w=10,h=7$ to verify 310.

21.10.4 Generalizing Throw and Throws for Custom Checks

The InvalidBoxDimensionException pattern generalizes: Any user-defined invariant — not present in the language's predefined ArithmeticException/IOException catalogue — can be turned into an exception hierarchy this way. You inherit from Exception (or a subclass) to fix whether the type lives in the checked or unchecked branch, you mark generators with throws YourException on the method/constructor header (compulsory for checked, optional for unchecked but still useful documentation), and you raise specific faults with throw new YourException(args) at the branch where the invariant fails. The compiler or runtime then ensures the fault is either declared or handled somewhere on the call stack.

General skeleton the professor advised you to copy for any domain check:

// 1. Define: choose checked vs unchecked root
class NegativeAgeException extends RuntimeException { // unchecked — domain programming error
    NegativeAgeException(int age){ super("negative age: "+age); }
}
// 2. Generate: validate and throw where the invariant fails
void setAge(int age) throws NegativeAgeException { // throws optional for unchecked, required for checked
    if (age < 0) throw new NegativeAgeException(age);
    this.age = age;
}
// 3. Guard: caller handles or forwards
try { person.setAge(-2); } catch (NegativeAgeException e){ System.out.println(e.getMessage()); }

Replace InvalidBoxDimensionException with InsufficientFundsException, InvalidScoreException, or any domain name — the steps are identical.

The professor also connected this to the MyException checked example from T6 Chapter 10: with class MyException extends Exception { MyException(int a){ detail=a; } public String toString(){return "MyException["+detail+"]";}} and static void compute(int a) throws MyException { if (a>10) throw new MyException(a); }, the driver must handle:

try { compute(1); compute(20); } catch (MyException e){ System.out.println("Caught " + e); }
// → Called compute(1) → Normal exit
// → Called compute(20) → Caught MyException[20]

The only difference from InvalidBoxDimensionException is the inheritance branch: extends Exception forces throws MyException at every call site, while extends RuntimeException keeps throws optional.

Visual — picture three vertical lanes labelled l, w, h feeding into a constructor gate Box(l,w,h). Each lane has a diamond ≤ 0? that, on failure, spawns a throwable arrow throw new InvalidBoxDimensionException(dim) diverting into a catch (InvalidBoxDimensionException e) basin that prints the offending dim and continues. The success path through all three diamonds leads to a box node labelled area = 2(lw+wh+hl) with a sample numeric bubble 5,10,7 → 310. X-axis is dimension order, y-axis is normal vs exceptional flow. One-sentence takeaway: validated dimensions converge either to area or to a domain-named throw.

21.10.5 Student Questions and Answers

Real-world — Custom exceptions like InvalidBoxDimensionException appear in production code to fail fast on invalid domain inputs with self-documenting exception names rather than returning silent error codes or -1. Frameworks check if (pageSize <= 0) throw new InvalidPageSizeException(pageSize) at API boundaries; service layers catch InsufficientFundsException separately from IOException; and validated-value objects (e.g., Box, Age, Score) enforce invariants at construction and let callers discriminate faults by catch type rather than by parsing a generic IllegalArgumentException message.

Exam Guidance Summary

All consolidated exam-specific guidance for this lecture — keep this as a quick checklist the night before the exam. Each bullet maps directly to a trace you have practiced in the sections above.

• Exam duration is two hours and will be conducted as an open-book exam. This was confirmed in response to a direct question at the end of this lecture.
• Syllabus scope: content covered in the contact session together with content available in the pre-contact and post-contact slides is included. The statement emphasized that the exam will include nothing apart from what is included — the included material is exactly the contact, pre-contact and post-contact content — so do not study beyond that boundary.
• Expect questions on interface fundamentals: the meaning of interface as a blueprint of a class, the compiler insertions public static final for every field and public abstract for every method as ease-of-use additions, and the strict class extends class vs class implements interface(s) vs interface extends interface(s) taxonomy.

Real-world: The exam is open-book, so organizing notes by these exact patterns — interface taxonomy, default/static resolution including InterfaceName.super, nesting qualifiers Outer.Inner vs Outer\\$Inner, exception hierarchy Throwable→Exception/Error and checked/unchecked contracts, multiple/nested catch wiring, and InvalidBoxDimensionException throw/throws lifecycle — allows rapid lookup rather than re-reading prose under time pressure.

Key Industry Applications

Consolidated real-world connections for quick reference — each maps the lecture pattern to a production Java idiom you will recognise in frameworks and libraries.

• Interface-based API design in Java frameworks — publishing a stable interface such as List, IntStack, or a domain Bank contract with only abstract declarations lets many teams (FixedStack vs DynStack, Client vs AnotherClient, multiple database drivers) implement it independently and be accessed polymorphically through the interface type at runtime.

• Multiple inheritance through interfaces enables a single service class to conform to several capability contracts at once (e.g., class ReportService implements Printable, Exportable, Auditable or class Trial implements Printable, Showable) without the ambiguity of inheriting two complete classes with conflicting instance state and method bodies.

• Default methods power evolution of Java's standard libraries — additions like Collection.forEach, Collection.removeIf, List.sort, List.replaceAll, and Stream defaults were shipped as default on long-published collection interfaces so that existing ArrayList/LinkedList implementations kept compiling while newer ones could override for performance.

• Static interface methods are invoked by interface name (e.g., Printable.show() or Comparator.comparing(...)) and are used for helper factories or validators that conceptually belong to the interface namespace rather than any single implementation instance — the call t.show() on an implementing object is not idiomatic.

• Conflicts of two default methods with the same signature (Printable.super.show() / Showable.super.show()) model real dependency diamond problems in library composition, resolved by explicit InterfaceName.super.method() delegation in the implementing class; a class that adopts two library interfaces with the same default name must override and choose.

• Nested interfaces of the form Outer.Inner model scoped contracts — for example, Map.Entry scoped inside Map, a top-level NetworkService exposing inner Callback, or a framework's Outer.Strategy — and the implicit static nature avoids requiring an outer instance just to name the inner contract type.

• Member inner classes used for tight coupling such as an ArrayList.Itr iterator class that needs private access to its enclosing collection's internal elementData array and size count, a GUI panel's listener that manipulates private fields of the outer panel, or a SceneComponent that toggles private selection flags via the inner iterator.

• Compiler artifacts Outer.class plus Outer\\$Inner.class (and Test\\$1.class for anonymous) appear in build outputs, coverage reports, and stack traces (Outer\\$Inner.show(Outer.java:6)); understanding the \\$ naming helps diagnose class-loading, shading, and serialization issues and explains why tools must be configured to instrument \\$ classes.

• Anonymous inner classes for one-off overrides — supplying an inline implementation of an abstract class or interface at the call site (button.addActionListener(new ActionListener(){...}), Collections.sort(list, new Comparator<Country>(){...}), one-shot Callback stubs) — with the single-object and "cannot expose extra() via outer type" constraints that make them lightweight but narrow.

• Local inner classes confine a helper class to a single method (void outerMethod(){ class Inner{...} Inner i = new Inner(); i.show(); }), reducing namespace pollution when the helper is meaningful only inside that method's scope, such as a method-local validator, parser state, or short-lived comparator not reused elsewhere.

• Static nested classes for grouping logically related utilities that need access only to static configuration of the outer class, including private static constants and factories (Map.Entry, Outer.Builder, configuration holders) without holding an outer instance and without leaking the Outer.this reference that a member inner would retain.

• Exception hierarchy (Throwable → Exception/Error, with IOException and RuntimeException subtrees under Exception) underpins production error handling — file and console code must try-catch or throws IOException for BufferedReader.readLine(), while arithmetic and indexing faults (ArithmeticException on a/0, ArrayIndexOutOfBoundsException on a[2] of length 2, NumberFormatException on Integer.parseInt) are caught as unchecked only where recovery is desired.

• Frameworks distinguish checked exceptions (compile-time contracts you must declare via throws and handle — e.g., SQLException, InterruptedException, IOException) from unchecked runtime exceptions (IllegalArgumentException, NullPointerException); user-defined unchecked exceptions like InvalidBoxDimensionException extends RuntimeException are used to fail fast on invalid domain inputs (e.g., non-positive box dimensions) with a self-documenting, domain-meaningful name rather than a silent error code or generic IllegalArgumentException.

• Nested and multiple-catch patterns and finally blocks appear in resource handling where finally { if (br != null) br.close(); } guarantees file, socket, or connection close and lock release whether the try succeeded or threw, and where outer try-catch scopes separate I/O faults (IOException) from business-logic faults (NumberFormatException) for appropriate recovery or escalation; modern try-with-resources builds on the same guarantees.