Question 1

In Java, what will the following program print when no exception is thrown in the try block? public class X { public static void main(String [] args) { try { badMethod(); System.out.print("A"); } catch (Exception ex) { System.out.print("B"); } final…

Accepted Answer

Introduction / Context:This question tests control flow through try/catch/finally when no exception occurs. The finally block always executes, regardless of whether an exception is thrown or caught. Given Data / Assumptions: badMethod() does nothing and throws no exception. try prints "A" after calling badMethod(). catch (Exception) prints "B" only if an Exception is thrown. finally always prints "C". After the try-catch-finally, "D" is printed. Concept / Approach:No exception is thrown, so the catch block is skipped. The finally block executes and then control continues after the try/catch/finally. Step-by-Step Solution: Call badMethod() → no exception.Print "A" inside try.Skip catch. Execute finally → prints "C".After the block, print "D". Verification / Alternative check:Add a throw in badMethod() and see how the flow changes (catch would run, but finally still runs). Why Other Options Are Wrong:"AC" misses the final "D"; "ABCD" would require an exception that is caught (printing "B"), which does not happen. Common Pitfalls:Thinking finally is conditional; forgetting the last print after the try/catch/finally. Final Answer:ACD

Question 2

In Java, what is the output of this program when a RuntimeException is thrown and handled, with a finally block executing? public class RTExcept { public static void throwit() { System.out.print("throwit "); throw new RuntimeException(); } public st…

Accepted Answer

Introduction / Context:This program demonstrates thrown unchecked exceptions (RuntimeException), catching with a broad Exception handler, and guaranteed execution of finally, followed by code after the try/catch/finally. Given Data / Assumptions: throwit() prints "throwit " then throws new RuntimeException(). try prints "hello " then calls throwit(). catch (Exception) handles the RuntimeException and prints "caught ". finally prints "finally ". After the block, println prints "after " with a newline. Concept / Approach:Unchecked exceptions (RuntimeException) do not require a throws clause. Once thrown, control transfers to the nearest matching catch, then finally runs, then execution continues after the try/catch/finally. Step-by-Step Solution: Output sequence: "hello " (from try) → "throwit " (from throwit) → exception thrown.Catch executes: prints "caught ".Finally executes: prints "finally ".After block: prints "after " and newline. Verification / Alternative check:Change catch to catch(RuntimeException) and behavior remains the same; removing catch would still run finally and then terminate with an exception. Why Other Options Are Wrong:They either omit finally/after or imply compilation errors that do not occur for unchecked exceptions. Common Pitfalls:Thinking unchecked exceptions must be declared; forgetting that finally runs even when an exception is thrown and caught. Final Answer:hello throwit caught finally after

Question 3

In Java, what happens when a method throws an Error that is not caught by catch(Exception), with a finally block present? public class X { public static void main(String [] args) { try { badMethod(); System.out.print("A"); } catch (Exception ex) { S…

Accepted Answer

Introduction / Context:This tests your understanding of Java's Throwable hierarchy and catch matching. Error is not a subtype of Exception; therefore catch(Exception) does not handle an Error. However, finally still executes. Given Data / Assumptions: badMethod() throws new Error(). try prints "A" only if no exception or error interrupts execution. catch catches only Exception (and its subclasses), not Error. finally always executes. Printing "D" happens only if control reaches after the try/catch/finally. Concept / Approach:Error represents serious problems that a reasonable application should not try to catch. Since Error is not an Exception, the catch(Exception) block will not handle it. The JVM unwinds the stack after finally runs. Step-by-Step Solution: badMethod throws Error → control jumps to finally (catch does not match).finally prints "C".Program terminates with an uncaught Error; "A" and "D" are not printed. Verification / Alternative check:Change the catch to catch(Throwable) or catch(Error) to handle it; then "C" would still print, and the program could continue to print "D". Why Other Options Are Wrong:They imply catch(Exception) would handle Error or that finally does not run, both incorrect. Common Pitfalls:Assuming Exception catches everything under Throwable; forgetting the special place of Error and its subclasses. Final Answer:C is printed before exiting with an error message.

Question 4

In Java, what will the following program print when a return occurs inside try and a finally block is present? public class Foo { public static void main(String[] args) { try { return; } finally { System.out.println("Finally"); } } }

Accepted Answer

Introduction / Context:This question focuses on the guarantee that finally executes even if the try block returns, breaks, or continues. The JVM ensures the finally block runs before control leaves the method. Given Data / Assumptions: try contains only return. finally prints "Finally". No exceptions are involved. Concept / Approach:Java specifies that the finally block executes after the try (and any matching catch) but before the method actually returns control to the caller. Therefore, the println in finally will run and produce output. Step-by-Step Solution: Enter try → encounter return.Before returning, run finally → prints "Finally".Method then completes with return; no further output. Verification / Alternative check:Place code after the try/catch/finally; it will be unreachable because of the return, but the finally still runs first. Why Other Options Are Wrong:Compilation is valid; there is definite output; no exception is thrown. Common Pitfalls:Believing that return suppresses finally; in Java it does not. Final Answer:Finally

Question 5

In Java, what will be printed when a try block runs normally and a finally block executes afterward? public class MyProgram { public static void main(String args[]) { try { System.out.print("Hello world "); } finally { System.out.println("Finally ex…

Accepted Answer

Introduction / Context:Java allows a try block with a finally block even without any catch clauses. The finally block guarantees cleanup or final actions after the try completes, whether or not an exception occurs. Given Data / Assumptions: try prints "Hello world " but throws no exception. finally prints "Finally executing " with println (newline at the end). No catch block is present; this is valid Java. Concept / Approach:When no exception is thrown, control flows from try to finally, then exits the method. Both outputs are printed in sequence. Step-by-Step Solution: Execute try: prints "Hello world ".Execute finally: prints "Finally executing " (followed by a newline).Program ends; combined output reads as "Hello world Finally executing". Verification / Alternative check:Add an exception inside try: the finally will still run before the program terminates or a catch (if present) runs. Why Other Options Are Wrong:Options claiming compilation failure are incorrect; Java permits try-finally without catch. Output is not only "Hello world." because finally adds more text. Common Pitfalls:Assuming a catch is mandatory with try; it is not if finally is present. Final Answer:Hello world Finally executing

Question 6

Java — Predict the console output for try/finally with a thrown exception: public class Test  {       public static void aMethod() throws Exception      {         try /* Line 5 */         {             throw new Exception(); /* Line 7 */         }  …

Accepted Answer

Introduction / Context:This Java question tests understanding of exception flow with try, finally, and catch in different call frames. It highlights that the finally block always executes, even when an exception is thrown and later caught in the caller. Given Data / Assumptions: aMethod throws a new Exception inside its try block. aMethod also has a finally block that prints "finally ". main calls aMethod inside a try and catches Exception, printing "exception " and then "finished". Concept / Approach:In Java, a finally block runs after try (and optional catch) completes, regardless of whether an exception is thrown. If an exception is not handled in the current method, it propagates outward, but the current method's finally still executes first. Step-by-Step Solution: Inside aMethod: throw new Exception() happens.Before leaving aMethod, finally runs and prints "finally ".Exception propagates to main and is caught by catch (Exception e), printing "exception ".After the try-catch in main, "finished" is printed. Verification / Alternative check:Comment out the catch in main to see the difference: you would still see "finally " before the program terminates with an uncaught exception. Why Other Options Are Wrong: "finally" alone ignores the catch and trailing print in main. "exception finished" ignores that finally executes in aMethod before control returns. "Compilation fails" is incorrect; the code is valid. Common Pitfalls:Assuming finally runs only if no exception is thrown; or assuming catch in main prints before the callee's finally. Final Answer:finally exception finished

Question 7

Java — Determine output with RuntimeException, multiple catch blocks, and finally: public class X  {       public static void main(String [] args)      {         try          {             badMethod();               System.out.print("A");           …

Accepted Answer

Introduction / Context:This problem checks exception selection among multiple catch blocks and confirms that finally always executes, followed by normal execution after the try-catch-finally completes. Given Data / Assumptions: badMethod throws RuntimeException. There are two catch blocks: first for RuntimeException, then for Exception. A finally block prints "D", and after the try-catch-finally, "E" is printed. Concept / Approach:Catch selection goes top-down: the first compatible catch handles the exception. RuntimeException matches the first catch, so the second catch is skipped. finally executes regardless, then the flow continues. Step-by-Step Solution: badMethod throws RuntimeException.catch (RuntimeException) executes and prints "B".finally executes and prints "D".After try-catch-finally, "E" prints. Verification / Alternative check:Swap the order of catch blocks (Exception first) to see a compilation error due to unreachable catch for RuntimeException. Why Other Options Are Wrong: "BD" omits the final "E". "BCD"/"BCDE" incorrectly assume both catches can run. Common Pitfalls:Expecting the code after throw to run (the "A" is never reached). Misunderstanding that only one matching catch runs. Final Answer:BDE

Question 8

Java — Identify the issue with catch ordering (general Exception before specific ArithmeticException): try  {      int x = 0;      int y = 5 / x;  }  catch (Exception e)  {     System.out.println("Exception");  }  catch (ArithmeticException ae)  {  …

Accepted Answer

Introduction / Context:This question checks knowledge that more specific exceptions must be caught before more general ones; otherwise the specific catch block is unreachable, causing a compile-time error. Given Data / Assumptions: Exception is the superclass of ArithmeticException. The code lists catch (Exception) before catch (ArithmeticException). Concept / Approach:Java requires catch blocks to be ordered from most specific to most general. If a general catch appears first, any subsequent specific catch for the same hierarchy is unreachable. Step-by-Step Solution: The compiler analyzes the catch sequence.Since Exception would catch ArithmeticException, the latter catch can never be reached.Java flags this as an error: unreachable catch block. Verification / Alternative check:Swap the two catch blocks: catch (ArithmeticException) first, then catch (Exception). The code will then compile and run printing "Exception" if you change the divisor to a non-zero value, or "Arithmetic Exception" for division by zero. Why Other Options Are Wrong:They assume execution proceeds; however compilation fails before runtime. Common Pitfalls:Believing that multiple catches for the same exception type could both run, or that order does not matter. Final Answer:Compilation fails.

Question 9

Java — Determine output when throwing a subclass exception and catching a superclass: class Exc0 extends Exception { }  class Exc1 extends Exc0 { } /* Line 2 */ public class Test  {       public static void main(String args[])      {          try   …

Accepted Answer

Introduction / Context:This validates understanding of exception inheritance and matching. A catch for a superclass type can handle exceptions of its subclass. Given Data / Assumptions: Exc1 extends Exc0, and both extend Exception (directly or indirectly). The code throws new Exc1(). First catch handles Exc0, second catch handles Exception. Concept / Approach:Java chooses the first catch whose parameter type is assignable from the thrown exception type. Since Exc0 is a superclass of Exc1, the first catch matches. Step-by-Step Solution: throw new Exc1() executes.catch (Exc0 e0) matches and executes, printing "Ex0 caught".Subsequent catch blocks are skipped. Verification / Alternative check:Swap the two catch blocks and observe that "exception caught" would execute instead because Exception would match first. Why Other Options Are Wrong:No compilation errors exist at the stated lines; the subclass relationship is valid. The second catch does not run because the first one already handled the exception. Common Pitfalls:Expecting a more general catch to run after a specific one; only the first matching catch executes. Final Answer:Ex0 caught

Question 10

Java — Output with unchecked exception, single broad catch, finally, and trailing print: public class X  {       public static void main(String [] args)      {         try          {             badMethod(); /* Line 7 */             System.out.print…

Accepted Answer

Introduction / Context:This reinforces exception handling flow: code after a throw is skipped, the matching catch runs, finally runs, and then execution continues after try-catch-finally. Given Data / Assumptions: badMethod throws RuntimeException (unchecked). There is a single catch (Exception) which covers RuntimeException. finally prints "C", and after the block "D" is printed. Concept / Approach:Throwing RuntimeException transfers control directly to catch. finally executes regardless, and execution then resumes after the try-catch-finally. Step-by-Step Solution: badMethod throws RuntimeException; "A" is not printed.catch (Exception) prints "B".finally prints "C".After the block, "D" prints. Verification / Alternative check:Remove the throw to see "A" followed by "C" and then "D". Why Other Options Are Wrong:They omit one or more required letters or assume "A" prints, which it does not. Common Pitfalls:Forgetting that finally runs even after a handled exception; and believing execution stops after catch (it continues). Final Answer:BCD

Question 11

Java exceptions (try/catch structure) — what is the most accurate statement about the following code snippet?  System.out.print("Start "); try  {  System.out.print("Hello world");  throw new FileNotFoundException(); } System.out.print(" Catch Here "…

Accepted Answer

Introduction / Context:This item probes correctness of Java’s try/catch syntax and catch ordering. It also indirectly touches on checked exceptions. You must decide whether the presented structure is valid and, if not, why. Given Data / Assumptions: A statement appears between the closing brace of the try block and the first catch. Two catch blocks then follow for EOFException and FileNotFoundException. Both exceptions are checked and extend IOException. Concept / Approach:In Java, a try block must be immediately followed by zero or more catch blocks and/or one finally block. No other statements are allowed between try { ... } and the first catch or finally. Placing a print statement between them breaks the grammar and causes a compile-time error, before any consideration of catch ordering. Step-by-Step Solution: Identify the illegal placement: System.out.print(" Catch Here "); on Line 7 intervenes between try and catch.Java grammar requires catch/finally to follow immediately. Therefore, the code does not compile.Even if that line were removed, the catch ordering shown (EOFException first, then FileNotFoundException) is legal because neither is a superclass of the other; both extend IOException. Verification / Alternative check:Move the “Catch Here” print either inside the try block or into a catch/finally block; compilation succeeds and the FileNotFoundException catch would execute. Why Other Options Are Wrong: All printed-output options assume the code runs; it will not compile in its current form. Common Pitfalls:Believing you can insert arbitrary statements between try and catch; the language forbids it. Final Answer:The code will not compile.

Question 12

Java I/O (checked exceptions) — will this program compile given that FileOutputStream.close() throws IOException?  import java.io.; public class MyProgram  {  public static void main(String args[])  {  FileOutputStream out = null;  try   {  out = ne…

Accepted Answer

Introduction / Context:This question focuses on Java’s checked exceptions and resource cleanup. Since FileOutputStream.close() declares throws IOException, calling it must be handled or declared. The code calls close() in finally without handling it. Given Data / Assumptions: Every method of FileOutputStream, including close(), can throw IOException. finally executes whether or not an exception occurs. There is no nested try/catch around out.close(), and main does not declare throws IOException. Concept / Approach:Checked exceptions must be either caught or declared. The compiler flags the call to out.close() as an unhandled checked exception. Additionally, out could be null if the constructor fails, but the compilation error is about the unhandled exception, not a NullPointerException (which would be a runtime concern). Step-by-Step Solution: Identify problem line: the finally block calls out.close().Since close() declares throws IOException, wrap it in a try/catch or test for null and handle exceptions.Without handling, compilation fails at this line. Verification / Alternative check:Fix by using try-with-resources or by writing finally { if (out != null) { try { out.close(); } catch(IOException e) { / handle */ } } }. Why Other Options Are Wrong: Earlier lines are fine; the constructor and write are already inside a try/catch that handles IOException. Claiming successful compilation ignores the checked-exception rule for the finally block. Common Pitfalls:Assuming code in finally does not need its own exception handling; it does. Final Answer:This program fails to compile due to an error at line 18.

Question 13

Java exceptions — select the true statement about try/catch/finally behavior and declaration requirements.

Accepted Answer

Introduction / Context:This question tests core rules about Java exception handling: when finally runs, whether a try requires a catch, and which exceptions must be declared or handled. Understanding these rules is essential for writing robust error-handling code. Given Data / Assumptions: We consider standard Java SE behavior (no suppressed VM bugs). “VM shutdown” includes System.exit, power loss, process kill, or similar hard-termination scenarios. Concept / Approach:A finally block is guaranteed to begin execution after the try block starts, regardless of whether an exception is thrown, provided the JVM does not terminate abnormally before it can start. Unlike catch, a finally may exist without any catch (i.e., try + finally only). Errors are unchecked; they need neither declaration nor mandatory handling. Step-by-Step Reasoning: Option A: False. Java allows try with a finally but no catch.Option B: False. Two identical catch clauses would make later ones unreachable (compile error).Option C: False. Error and RuntimeException are unchecked and need not be declared or caught.Option D: True. Once the try starts, the associated finally is guaranteed to start (barring VM shutdown), even if a return occurs inside try or catch. Verification / Alternative check:Write a small example with returns or thrown exceptions; the finally still runs, confirming the guarantee. Why Other Options Are Wrong: They contradict Java’s specification for checked vs unchecked exceptions, reachability, and try/finally requirements. Common Pitfalls:Believing try must always have a catch, or thinking Error must be declared like IOException. Final Answer:Except in case of VM shutdown, if a try block starts to execute, a corresponding finally block will always start to execute.

Question 14

In Java exception handling, which statement is actually true about catch blocks and throwable categories?

Accepted Answer

Introduction / Context:This item tests core Java exception-handling concepts: the Throwable hierarchy, catch clause matching, and when try blocks are required. Understanding how the catch type relates to thrown exceptions is essential for writing robust error handling code. Given Data / Assumptions: X is a subclass of Exception. We are comparing behaviors of catch typing, the nature of Error, and whether try blocks are mandatory. Java's compile-time checking applies to checked exceptions only. Concept / Approach:Java chooses a catch block based on the thrown object's runtime type. A catch parameter typed to a superclass will match any instance of that type or its subclasses. Errors are not RuntimeException; both Error and Exception extend Throwable independently. Checked exceptions must be caught or declared; unchecked (RuntimeException and Error) need not be caught or declared. Step-by-Step Solution:Identify hierarchy: Throwable → {Error, Exception}; RuntimeException extends Exception, not Error.Catch matching: catch(X) matches X and any subclass of X.Try requirement: only checked exceptions force try/catch or throws; Error is unchecked.Therefore, only the statement about catch(X x) catching subclasses of X is correct. Verification / Alternative check:Write a small program that throws a subclass of X and observe that catch(X) handles it; attempting to equate Error with RuntimeException will not compile logically or by documentation. Why Other Options Are Wrong:Option B: Error is not a RuntimeException. Option C: Errors are unchecked; no try required. Option D: You may declare throws instead of enclosing in try for checked exceptions. Option E: Incorrect because option A is true. Common Pitfalls:Confusing unchecked Errors with checked Exceptions; assuming try is always required; misunderstanding catch polymorphism. Final Answer:catch(X x) can catch subclasses of X where X is a subclass of Exception.

Question 15

In Java, what is the precise output order and behavior for this program using a try/finally with a thrown RuntimeException? public class MyProgram {  public static void throwit() { throw new RuntimeException(); }  public static void main(String args…

Accepted Answer

Introduction / Context:This question probes your understanding of try/finally semantics and unchecked exceptions in Java. It matters whether finally executes before, after, or instead of exception propagation and what happens to statements following a throw inside try. Given Data / Assumptions: throwit() throws a RuntimeException (unchecked). There is no catch block; only finally is present. System.out prints are line-buffered but order is deterministic. Concept / Approach:When a throw occurs inside a try and no catch handles it, the JVM still guarantees execution of the finally block before the exception propagates out. Any statements in the try after the throw are skipped. After finally runs, the uncaught exception reaches the runtime, which prints a stack trace (or an error line) after the program's own output. Step-by-Step Solution:Prints: "Hello world " from the first println.throwit() is invoked and throws RuntimeException immediately."Done with try block " is never reached.finally executes and prints "Finally executing ".The unhandled RuntimeException then propagates; the JVM prints the exception message/stack trace after finally. Verification / Alternative check:Insert a catch before finally and observe the change; or run the code and see the printed order with the stack trace last. Why Other Options Are Wrong:Option B places the exception message before finally and claims the skipped try println executes. Option C omits the mandatory finally execution. Option A/E are incorrect because the code compiles and certainly produces output. Common Pitfalls:Assuming finally executes after program termination or that an exception bypasses finally; both are incorrect. Final Answer:The program will print Hello world, then will print Finally executing, then will print that a RuntimeException has occurred.

Question 16

Java checked exception propagation: at Point X on line 5, what must be added so test() compiles when runTest() declares throws TestException? public class ExceptionTest {  class TestException extends Exception {}  public void runTest() throws TestEx…

Accepted Answer

Introduction / Context:This question focuses on Java's checked exception rules. A method that calls another method which declares a checked exception must either handle it with a try/catch or declare it in its own throws clause with the same type or a supertype. Given Data / Assumptions: runTest() declares throws TestException, which is a checked exception. test() calls runTest() directly. No try/catch surrounds the call in test(). Concept / Approach:For checked exceptions, the compiler enforces one of two options: catch the exception locally, or declare it. Declaring throws Exception on test() is legal because Exception is a supertype of TestException. A try/catch could work too, but the prompt asks what to add “at Point X” in the method signature, not inside the body. Step-by-Step Solution:Identify the thrown type: TestException extends Exception.To compile, test() must either catch or declare.Adding throws Exception to the signature satisfies the rule because it covers TestException.Therefore, the correct addition is a throws clause with Exception (or TestException). Verification / Alternative check:Replace with throws TestException and recompile; it also succeeds. Wrapping in try { runTest(); } catch(TestException e){} would also compile. Why Other Options Are Wrong:Option A: Compiler error persists without handling/declaring. Option C: A catch cannot be added at the signature point; it belongs inside the method body. Option D: Declaring RuntimeException does not satisfy checked-exception requirements. Option E: final is unrelated. Common Pitfalls:Thinking any throws clause will do; it must be the same checked type or a supertype. Final Answer:throws Exception

Question 17

Java "throw" targets: which of the following types can legally be thrown with the throw statement? Consider: 1) Error, 2) Event, 3) Object, 4) Throwable, 5) Exception, 6) RuntimeException.

Accepted Answer

Introduction / Context:This question checks your knowledge of Java’s Throwable hierarchy and the compile-time rules governing the throw statement. Only objects whose types extend Throwable may be thrown. Given Data / Assumptions: Candidate types: Error, Event, Object, Throwable, Exception, RuntimeException. We must select all and only the types permitted by the Java Language Specification for throw. Concept / Approach:The throw statement requires an expression of type Throwable or a subtype. The hierarchy is: Throwable → {Error, Exception}. RuntimeException extends Exception. Neither Event nor a bare Object derives from Throwable, so they cannot be thrown. Step-by-Step Solution:Check 1) Error: subclass of Throwable ⇒ allowed.2) Event: not a Throwable ⇒ not allowed.3) Object: root of all objects but not a Throwable ⇒ not allowed.4) Throwable: allowed.5) Exception: allowed.6) RuntimeException: allowed.Hence, the correct set is 1, 4, 5, and 6. Verification / Alternative check:Try throw new Object(); in a test program; it fails to compile. Replace with throw new Throwable(); or throw new Error(); and it compiles (with appropriate handling/declaring for checked types). Why Other Options Are Wrong:Options A/B/D include non-Throwable types (Event or Object) and are therefore invalid. Common Pitfalls:Confusing “any object” with Throwable-only; forgetting that RuntimeException is a subclass of Exception and both are Throwable. Final Answer:1, 4, 5 and 6

Exceptions Questions

Questions

Practice smarter