Exception Handling and Development Tools practice questions

RuntimeException

Why wrong: RuntimeException is unchecked; the caller is not forced to handle it.

Exception

Why wrong: Exception is too general; should use a more specific subclass.

IOException

Why wrong: IOException is broader than needed; FileNotFoundException is more specific.

Ignore the exception because it is not declared.

Why wrong: The compiler will force handling of checked exceptions.

Declare the library's exception in the method signature.

Why wrong: The exception is not declared in the library method, so the compiler won't allow it.

Catch the exception and log it, then continue execution.

Why wrong: This may hide the error and might not be appropriate if the error is fatal.

Close resources in a finally block without null checks.

Why wrong: Null checks are needed to avoid NullPointerException.

Rely on garbage collection to close resources.

Why wrong: Garbage collection does not close resources like streams.

Use a try-catch block and close resources in the catch block.

Why wrong: Resources should be closed in finally or by try-with-resources.

Review the code manually to trace all possible callers.

Why wrong: This is time-consuming and error-prone.

Run a static analysis tool to detect the issue.

Why wrong: Static analysis cannot reproduce the exact runtime call path.

Add log statements at the beginning of the method.

Why wrong: This requires code changes and recompilation.

It translates Java source code into native machine code.

Why wrong: The compiler outputs bytecode, not machine code.

It produces executable files that run directly on the OS.

Why wrong: Bytecode requires JVM to run.

It executes Java programs.

Why wrong: Execution is done by JVM.

Ignore the exception since it is checked.

Why wrong: Checked exceptions must be handled or declared.

Add a throws clause to the calling method.

Why wrong: This does not handle the exception; it propagates it.

Use a finally block without catch.

Why wrong: Finally does not handle exceptions.

jar

Why wrong: jar is for archiving.

javac

Why wrong: javac is the compiler.

javadoc

Why wrong: javadoc generates documentation.

A try block must be followed by either a catch or finally.

Why wrong: Try can be followed by catch and/or finally, but finally is optional if catch is present.

The finally block executes only if an exception is thrown.

Why wrong: Finally executes whether exception occurs or not.

The finally block cannot contain a return statement.

Why wrong: It can contain a return; but it is not recommended.

ArrayIndexOutOfBoundsException

Why wrong: It is a RuntimeException (unchecked).

NullPointerException

Why wrong: It is a RuntimeException (unchecked).

Line 30

Why wrong: Not mentioned in the stack trace.

Line 10

Why wrong: Line 10 is in Main.java, not the source of the exception.

Line 15

Why wrong: Not mentioned in the stack trace.

Add a throws FileNotFoundException clause to the main method.

Why wrong: This would compile but the exception is not handled; it propagates to JVM. The question says 'fix', and both A and B resolve the error, but A is the typical fix for this scenario. However, based on typical exam logic, A is the direct fix. I'll mark A as correct; B is plausible but not the best practice.

Change FileReader to BufferedReader.

Why wrong: BufferedReader constructor also throws FileNotFoundException.

Use FileInputStream instead.

Why wrong: FileInputStream also throws FileNotFoundException.

Add --add-opens java.base/java.lang=ALL-UNNAMED to the JVM command line.

Why wrong: You cannot modify JVM startup scripts per the scenario.

Use sun.misc.Unsafe to access the String field directly.

Why wrong: Unsafe still requires reflection and is not a solution.

Add 'opens java.lang;' to the module-info.java file.

Why wrong: You cannot open java.lang from your module; it's a system module.

A throws declaration in the method signature

Why wrong: throws only propagates the exception, does not close resources.

A finally block without any resource declaration

Why wrong: Finally alone does not automatically close resources.

A try-catch-finally block with explicit close in finally

Why wrong: Explicit close might be missed if not properly written.

ArrayIndexOutOfBoundsException

Why wrong: ArrayIndexOutOfBoundsException is an unchecked exception.

ArithmeticException

Why wrong: ArithmeticException is an unchecked exception (RuntimeException subclass).

NullPointerException

Why wrong: NullPointerException is an unchecked exception.

The caller must catch only FileNotFoundException.

Why wrong: Both exceptions must be handled or declared.

The caller can declare throws Exception to cover both.

Why wrong: Declaring throws Exception is allowed but not the only option; also, it's not a must.

The caller can ignore both exceptions.

Why wrong: Checked exceptions must be handled or declared.

The exception is caught and handled by the finally block.

Why wrong: finally does not catch exceptions; it's for cleanup.

The finally block does not execute if an exception occurs.

Why wrong: finally always executes unless JVM exits.

The method exits immediately without executing finally.

Why wrong: finally executes even on exception.

jar

Why wrong: jar creates or extracts JAR archives.

javadoc

Why wrong: javadoc generates documentation from source code.

java

Why wrong: java runs .class files, not compiles them.

Throwable

Why wrong: Extending Throwable is possible but not standard; Exception is the intended parent.

Error

Why wrong: Extending Error creates an unchecked exception, not meant for recoverable conditions.

RuntimeException

Why wrong: Extending RuntimeException creates an unchecked exception.