Unit 4 - Practice Quiz

By definition, a class that is declared inside another class or interface is called a nested class. This is done to group classes that are only used in one place, which increases encapsulation.

A static nested class is associated with its outer class, not an instance. Therefore, you can create an object of a static nested class without first creating an object of the outer class.

An anonymous class is an inner class without a name. Since it has no name, it is both declared and instantiated in a single expression, typically used for creating a one-time-use object.

A functional interface in Java is an interface that contains exactly one abstract method. This is a requirement for it to be the target of a lambda expression. The @FunctionalInterface annotation can be used to enforce this rule.

The basic syntax of a lambda expression consists of a parameter list, the arrow token ->, and a body. For example: (parameter) -> { body }.

java.time.LocalDate is the modern, immutable class for representing a date without time-of-day or timezone information. The older java.util.Date and java.util.Calendar classes are now largely considered legacy.

Exception handling allows a program to deal with unexpected situations (errors) in a controlled way, preventing an abrupt crash and enabling recovery or graceful termination.

The Throwable class is the superclass of all errors and exceptions in Java. Its two main subclasses are Error (for severe system issues) and Exception (for conditions that applications might want to catch).

If an exception propagates all the way up the call stack without being caught, it reaches the Java Virtual Machine (JVM), which will terminate the program and typically print a stack trace.

The finally block is designed to contain cleanup code (like closing files or database connections) that must run no matter what happens in the try block, ensuring resources are released properly.

The throw keyword is used within a method body to explicitly throw an instance of an exception. In contrast, the throws keyword is used in a method signature to declare exceptions that the method might propagate.

The multi-catch feature, introduced in Java 7, uses a single vertical bar | to separate the different exception types that the catch block can handle.

The try-with-resources statement automatically calls the close() method on any resource declared in its parentheses. This is possible only for classes that implement the AutoCloseable interface (or its subinterface Closeable).

Checked exceptions are those that the compiler forces you to handle. To create one, you must extend the java.lang.Exception class or one of its subclasses (that is not RuntimeException).

The assert keyword is used to declare an assertion. It checks if a boolean condition is true and throws an AssertionError if it is false. Assertions are primarily for debugging and are disabled by default.

A key feature of an inner class (non-static nested class) is that it is associated with an instance of its outer class and can access all of that instance's fields and methods, even the private ones.

Local classes are defined within the scope of a block, typically a method body. They are not visible outside of that block and can be useful for very localized, specific tasks.

Lambda expressions are essentially anonymous functions—blocks of code with parameters—that can be treated as a value. They provide a clear and compact way to implement a method of a functional interface.

The try block is used to surround the segment of code where an exception might occur. If an exception is thrown within this block, the JVM looks for a corresponding catch block to handle it.

Unchecked exceptions (subclasses of RuntimeException) represent programming errors that are typically not expected to be recovered from, like trying to access a method on a null reference. IOException and SQLException are examples of checked exceptions, which must be handled.

A static nested class does not have access to the non-static (instance) members of its outer class. The outerVar is an instance variable, so the static class StaticNested cannot access it directly. This will result in a compilation error stating 'non-static variable outerVar cannot be referenced from a static context'.

A non-static nested class (or inner class) is associated with an instance of its outer class. To create an instance of the inner class, you must first have an instance of the outer class. The correct syntax is outerInstance.new InnerClassName().

Starting from Java 8, a local or anonymous class can access local variables of the enclosing scope that are effectively final. An effectively final variable is one whose value is never changed after it is initialized. Since count is initialized to 1 and never modified, it is effectively final and can be accessed by the anonymous Greeter implementation. Therefore, the code compiles and runs successfully.

A functional interface must have exactly one abstract method. The Calculator interface declares two abstract methods (calculate and subtract), so it is not a functional interface. The other options are valid: Printer has one abstract method and a default method. Validator has one abstract method and a static method. Runnable has only one abstract method, run().

The code processes a list of names. The first filter s -> s.length() > 3 keeps elements with more than 3 characters: ["Alice", "Charlie"]. The second filter s -> s.startsWith("A") is applied to this reduced stream, which only keeps elements starting with 'A'. From ["Alice", "Charlie"], only "Alice" satisfies this condition. Therefore, "Alice" is the only name printed.

The finally block is always executed after the try block, regardless of whether an exception occurred. If both the try (or catch) block and the finally block have return statements, the value returned from the finally block will override the value from the try/catch block. Here, the try block prepares to return 1, but then the finally block executes and returns 3, which becomes the final return value of the method.

methodB throws a NullPointerException. This exception propagates to its caller, methodA. The catch block in methodA only catches ArithmeticException, so it cannot handle the NullPointerException. The exception continues to propagate up to main. The catch block in main catches Exception (which is a superclass of NullPointerException), so it handles the exception. The program flow is: print "In method A", print "In method B", exception thrown, print "Caught in main", and finally print "End of main".

The throws keyword is a declaration used in a method's signature to indicate to the caller that the method might throw one of the listed checked exceptions. The caller must then handle or propagate it. The throw keyword is an action used inside a method body to explicitly create and throw an exception object, causing an immediate halt in normal program flow.

In Java, custom exceptions are created by extending an existing exception class. To create a checked exception, which the compiler forces you to handle, you should extend the java.lang.Exception class. Extending RuntimeException creates an unchecked exception. Extending Error is reserved for serious system-level problems and is not recommended for application-level exceptions.

In a try-with-resources statement, the resource is initialized first ("Resource created"). Then, the try block is executed. Inside r.use(), "Resource used" is printed, and a RuntimeException is thrown. Before the exception is passed to the catch block, the finally block implicitly created by the try-with-resources statement is executed, which calls the close() method ("Resource closed"). Finally, the catch block executes and prints the exception message.

The multi-catch syntax catch (Type1 | Type2 e) is a convenient way to handle multiple exception types with the same code block. A key rule for this feature is that the exception parameter (e in this case) is implicitly final. This means you cannot reassign it a new value within the catch block. Attempting to do so, as shown on Line X, results in a compilation error.

When assertions are enabled with the -ea (enable assertions) VM argument, the assert statement is executed. In this case, result is -20.0, so the condition result >= 0 is false. This causes an AssertionError to be thrown, with the provided message included. The program terminates at that point, and "Calculation finished." is never printed.

The java.time API is designed to handle date arithmetic intelligently. When adding one month to January 30th, the API recognizes that February 2023 does not have 30 days. Instead of throwing an error or rolling over into the next month, it adjusts the date to the last valid day of the target month, which is February 28th, 2023.

When catching multiple exceptions, the catch blocks must be ordered from the most specific subclass to the most general superclass. If a superclass (IOException) is caught before a subclass (FileNotFoundException), the subclass's catch block would become unreachable code, resulting in a compilation error. The correct approach is to catch the more specific exceptions first, followed by their parent class.

If an exception is thrown in the try block and another exception is thrown in the finally block, the exception from the finally block is the one that gets propagated up the call stack. The original exception from the try block is 'suppressed' and attached to the new exception. This ensures that the finally block's critical cleanup code can signal its own failure, which might be more important than the original error.

The calculate method expects an object of type Operator. A lambda expression can be used to provide an implementation for the operate method on the fly. The expression (a, b) -> a * b matches the signature int operate(int x, int y). The types of a and b are inferred by the compiler. Option B has incorrect syntax for parameter types. Option C has a block body but is missing the return keyword. Option D has incorrect overall syntax.

A local class is defined within a method block. Its scope is limited to that block. It cannot have access modifiers like public or private. It cannot have static members (unless they are constant variables). Crucially, for data consistency, it can only access the local variables of its enclosing method if those variables are not modified after initialization (i.e., they are final or effectively final).

A static nested class is essentially a regular class that has been nested inside another for packaging convenience. It does not have an implicit reference to an instance of the outer class, which makes it more memory-efficient. It's the ideal choice for a helper class that is logically grouped with the outer class but operates independently of any specific instance of it. Non-static inner classes are used when the nested class needs to be tightly coupled with an instance of the outer class.

A method is allowed to declare that it throws a checked exception even if its current implementation does not actually throw one. The throws clause is part of the method's contract, warning callers that a future version of this method might throw that exception. The caller (main method) correctly handles this possibility with a try-catch block. Since no exception is actually thrown, the catch block is not executed.

When a method calls another method that declares a checked exception in its throws clause, the calling method has two options to satisfy the compiler. Option A: It can handle the exception immediately using a try-catch block. Option C: It can propagate the exception by declaring it in its own throws clause, making its own caller responsible for handling it. Option B is incorrect because it neither handles nor declares the checked exception, leading to a compilation error.

The code compiles and runs successfully. The key is understanding variable shadowing and access rules. Inside the Inner class's display method: x refers to the Inner class's instance variable (value 30). this.x is the same. Outer.this.x explicitly refers to the Outer class's instance variable (value 20), which is then updated to 25. Outer.y refers to the Outer class's static variable (value 10). A non-static inner class holds an implicit reference to its enclosing instance, allowing it to access and modify even private members of the outer class, which is demonstrated by Outer.this.x = 25.

A local or anonymous class can only access local variables of the enclosing scope that are final or effectively final. A variable is effectively final if its value is not changed after initialization. In this code, the variable z is modified (z++) after the anonymous Runnable is defined. This modification violates the effectively final rule, causing a compilation error. The compiler needs to be sure that the value of z captured by the anonymous class will not change.

The lambda expression () -> {} is a valid implementation for both the Processor and Executor functional interfaces, as both define a single abstract method that takes no arguments and returns void. When test.execute(...) is called, the compiler cannot determine which of the two overloaded execute methods to invoke because the lambda is a compatible target type for both. This ambiguity results in a compilation error. To resolve this, the lambda would need to be explicitly cast, e.g., test.execute((Processor) () -> {});.

This question tests the precedence of return statements within try-catch-finally blocks.

1. The try block executes and sets value to 10. It then encounters a return statement.
2. Before the method can actually return 10, the finally block must execute.
3. Inside finally, the value is changed to 30, and another return statement is encountered.
4. A return statement in a finally block will always override any return from the corresponding try or catch block. Therefore, the method terminates and returns the value from the finally block, which is 30. The output reflects the print statement from finally and the final returned value.

In a try-with-resources statement, if an exception is thrown in the try block and another exception is thrown when close() is called, the exception from the try block is the primary one that is propagated. The exception from the close() method is suppressed and attached to the primary exception. In this case, resource.action() throws the first RuntimeException ("Action Error"). When the try block completes (abruptly), the close() method is called, which throws a second RuntimeException ("Close Error"). The catch block catches the primary exception. The suppressed exception can be retrieved by calling e.getSuppressed(), which reveals the exception from close().

The rules for overriding a method with a throws clause for checked exceptions are strict. The overriding method can:

1. Not declare any checked exception.
2. Declare the same checked exception as the superclass method.
3. Declare a subclass of the checked exception declared in the superclass method.
   It cannot declare a broader (superclass) exception or a new checked exception that is not in the same hierarchy. FileNotFoundException is a subclass of IOException, so it is a valid, more specific exception to throw. Exception and Throwable are superclasses (broader), and SQLException is an unrelated checked exception, making them all invalid overrides.

A functional interface must have exactly one abstract method. However

A functional interface must contain exactly one abstract method.

• Option A is incorrect because it declares two abstract methods (compute and log).
• Option B is incorrect because it declares zero abstract methods; it only has a default method.
• Option C is incorrect because interface methods are implicitly public. Attempting to redeclare toString (which is public in Object) with protected visibility is a compilation error.
• Option D is correct. It has one abstract method, compute(). The equals(Object obj) method does not count because it is an abstract method from java.lang.Object. Static methods like log() also do not count towards the single abstract method rule. Therefore, it satisfies the criteria for a functional interface.

The key requirements are that the issue is recoverable and the caller must be forced to handle it.

• Extending RuntimeException (Option A) creates an unchecked exception. The compiler does not force the caller to handle it, which is against the requirement.
• Extending Error (Option D) is incorrect. Errors are for critical, unrecoverable problems in the JVM itself (like OutOfMemoryError), not for application-level issues.
• Extending IOException (Option C) might seem plausible, but it's overly specific. The problem is a transient API issue, which might not be strictly I/O related (e.g., a rate limit error). It's better to create a more specific exception type for your application's domain.
• Extending Exception (Option B) creates a checked exception. This forces the API caller to either catch the exception or declare it in a throws clause, perfectly matching the requirement that the caller must handle this recoverable condition.

Let's refine the question to be trickier. What if the assertion passes but has a side effect?

java
public class Main {
public static void main(String[] args) {
int x = 10;
System.out.println("x before assertion: " + x);
assert modifyAndCheck(x);
System.out.println("x after assertion: " + x);
}
private static boolean modifyAndCheck(int val) {
// This method has a side effect, which is bad practice.
val = val + 5;
return val > 10;
}
}
In this case, val is a local copy, so x in main is not modified. Output would be 10 and 10.

Let's go back to the original idea but make the assertion pass.

java
// In Main.java
public class Main {
public static void main(String[] args) {
int x = 10;
System.out.println("x before assertion: " + x);
assert x++ >= 10 : "x should be >= 10";
System.out.println("x after assertion: " + x);
}
}

Here, x is 10. 10 >= 10 is true. The assertion passes. The side effect x++ still occurs. x becomes 11. The program continues and prints the new value of x. This is a great hard question because it relies on knowing both that the side effect happens and that the assertion condition passes. Let's use this version.

Final check: java -ea Main. x is 10. assert x++ >= 10. The expression x >= 10 is evaluated with x=10, which is true. The assertion passes. The post-increment x++ then updates x to 11. The next line prints x after assertion: 11. This is correct. If run without -ea, the assert line is skipped entirely, and the output would be ... 10 and ... 10.

When assertions are enabled via the -ea flag, the expression inside the assert statement is evaluated. The expression here is x++ >= 10. Crucially, expressions in assertions are always evaluated if assertions are on, including any side effects.

1. The value of x (which is 10) is used for the comparison 10 >= 10. This evaluates to true, so the assertion passes and no AssertionError is thrown.
2. The post-increment operator ++ then updates the value of x to 11.
3. The program continues to the next line, which prints the new value of x. This demonstrates the danger of side effects in assertions, as program behavior can change depending on whether assertions are enabled.

This demonstrates exception transformation and propagation.

1. methodC throws an IOException.
2. methodB's try block calls methodC, and the IOException is caught by catch (IOException e). It prints "Caught in B: Original".
3. Inside the catch block, a new RuntimeException is thrown.
4. Before methodB propagates this new exception, its finally block must execute, printing "Finally in B".
5. The RuntimeException (which is unchecked) propagates up to methodA.
6. methodA's catch block is catch (RuntimeException e), which successfully catches the transformed exception from methodB. It prints "Caught in A: Transformed". The original IOException is effectively consumed and replaced by the RuntimeException.

The Java compiler enforces a rule for multi-catch blocks to prevent redundant code. If you list multiple exception types, none of them can be a superclass or subclass of another in the same catch clause. In this example, FileNotFoundException is a direct subclass of IOException. Therefore, catch (IOException e) would already handle any FileNotFoundException. The compiler flags catch (IOException | FileNotFoundException e) as an error because the FileNotFoundException part is unreachable and redundant. The variable e is indeed implicitly final in a multi-catch, but you can still call methods on it; you just can't reassign it.

This question tests the handling of DST transitions in the java.time API. The initial time is 2024-03-10T01:30 with the standard offset for New York (-05:00). We add a Duration of 2 hours. A Duration represents an exact number of seconds (2 * 3600 seconds in this case) on the timeline. Adding 2 hours to 01:30 would arithmetically be 03:30. The ZonedDateTime API is DST-aware. At 02:00 on this date, the clock springs forward to 03:00, and the time zone offset changes from -05:00 (EST) to -04:00 (EDT). The API correctly calculates the resulting time as 03:30 and applies the new, correct offset for that time, which is -04:00.

While it is syntactically possible to catch an Error, it is strongly discouraged because Error and its subclasses (like StackOverflowError) signify critical problems that a reasonable application should not try to handle. The recursive call to causeStackOverflow() will quickly exhaust the stack space and throw a StackOverflowError. Even though there is a catch(Error e) block, the JVM is in a precarious state. The finally block is almost always guaranteed to run, so it will print "Finally". However, after catching the error, the program cannot be expected to recover gracefully. The default main thread's uncaught exception handler will print the stack trace of the StackOverflowError, and the program will terminate abruptly. The line "Finished" will never be reached.

This tests the scope and capture mechanism of an anonymous class. The anonymous class implementing Speaker is defined inside the create method. It captures the value of the greeting parameter. The key is that it captures the value of the reference sb, not the StringBuilder object itself. Inside the main method, a StringBuilder with the value "10" is created. The create method is called, and the anonymous class instance is created, capturing the reference to this StringBuilder. After create returns, the line sb.append("1") modifies the same StringBuilder object that the Speaker instance holds a reference to. However, the say() method of the anonymous class uses the captured local variable greeting, not the instance field sb. The local variable greeting was never modified within the create method and its captured value remains a reference to the StringBuilder as it was when passed. Thus, when say() is called, it accesses the greeting field, which was assigned the value of the StringBuilder's toString() method at the time of the anonymous class's creation. The greeting field is a String, which is immutable. It was initialized to "10" and never changed. Therefore, it prints "Anonymous says: 10". If the anonymous class used sb.toString() directly in say(), the output would be "11".

This code fails to compile due to an access rule violation. A static nested class (StaticInner in this case) does not have an enclosing instance of the outer class. Therefore, it cannot directly access non-static members of the outer class. The line System.out.println("Accessing: " + o_var); inside StaticInner.run() is trying to access o_var, which is a non-static instance variable of Outer. This is illegal and will result in a compilation error. A static nested class can only access static members of its enclosing class directly or non-static members through an explicit instance of the outer class (e.g., new Outer().o_var).

The try-with-resources statement has a strict order of operations.

1. Initialization: Resources are initialized in the order they are declared. So, new R1() is executed first (printing "Creating R1"), followed by new R2() (printing "Creating R2").
2. Execution: The try block is executed (printing "Running...").
3. Closing: When the try block finishes, the resources are closed in the reverse order of their initialization. Therefore, r2.close() is called first (printing "Closing R2"), and then r1.close() is called (printing "Closing R1"). This LIFO (Last-In, First-Out) order for closing resources is crucial for managing dependencies correctly.

This is a classic problem with creating recursive lambdas. A local variable must be definitely assigned before it is used. In the statement Function<Integer, Integer> factorial = n -> ..., the right-hand side (the lambda expression) is evaluated to create an object to assign to the left-hand side (factorial). Inside the lambda body, the code refers to the variable factorial itself (factorial.apply(n - 1)). At this point, the compiler sees factorial being used before it has been assigned a value, leading to a compilation error. A common way to solve this is to use an instance variable or a static field, or a more complex construct like a y-combinator, so that the variable is in scope and initialized before the lambda body is defined.

A key characteristic of a non-static inner class (or member inner class) is that each of its instances holds a hidden, implicit reference to the instance of the outer class that created it. This reference is what allows the inner class to access members of the outer class. As long as the Inner instance is reachable (i.e., a strong reference to it exists), that implicit reference to the Outer instance will also be maintained. Because the Outer instance is still reachable through the Inner instance, it is not eligible for garbage collection. This behavior is a common source of memory leaks in Java if inner class instances are unintentionally kept alive.

This demonstrates exception handling with re-throwing.

1. level2() is called and immediately throws a new SQLException.
2. The catch block in level1() catches this exception.
3. Inside the catch block, it prints Level 2.
4. The line throw e; re-throws the exact same SQLException object that was caught.
5. The finally block in level1() executes before the exception propagates further, printing Level 1.
6. The SQLException is now propagated out of level1() and into main().

Java's exception philosophy distinguishes between recoverable conditions (checked exceptions, extending Exception) and programming errors/bugs (unchecked exceptions, extending RuntimeException). An InvalidStateException suggests that the program has reached a state it should not have, which is typically a bug or a logic error on the programmer's part. For such errors, an unchecked exception (extending RuntimeException) is the appropriate choice. Forcing callers to try-catch a bug they cannot realistically recover from is considered poor API design. The code is syntactically correct, but it violates a key design principle. The other options are incorrect: providing a cause is a standard and recommended practice, and there are no rules against subclassing exceptions or having multiple constructors.