Question 90 of 481
1Z0-811 Exception Handling and Development Tools Practice Question
You are maintaining a multi-threaded banking application that processes transactions. In the `processTransaction` method, you have a try-catch block that catches `Exception` to handle any unexpected errors. Recently, the application intermittently fails to update account balances correctly due to unhandled exceptions. The logs show that sometimes a `RuntimeException` is thrown from a nested method, but it is not being logged or handled properly, leading to inconsistent state. The team wants to improve the exception handling to ensure that all exceptions are caught, logged, and the transaction is rolled back properly. The method currently uses a primitive try-catch-finally where the finally block commits the transaction if no exception occurred. Which approach best addresses the issue while maintaining clarity and correctness?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Inside the try block, set a boolean success flag to true upon completion; in the finally block, check the flag: if false, rollback; if true, commit. Additionally, catch specific exceptions, log them, and ensure rollback logic is invoked.
Option C is correct because it uses a boolean success flag set inside the try block; the finally block checks the flag to commit only if success, and rolls back otherwise. This ensures the transaction is committed only when no exception occurred. Additionally, catching specific exceptions (including RuntimeException) and logging them provides proper error handling. Option A is wrong because removing the catch block eliminates the ability to log and handle exceptions specifically, even though a boolean flag in finally can manage the commit/rollback. Option B is wrong because even though it adds a catch for RuntimeException and calls rollback, the finally block still unconditionally commits afterward, which can override the rollback. Option D is wrong because declaring throws Exception pushes the rollback responsibility to the caller without resolving the local transaction consistency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove the `catch (Exception e)` block and rely solely on the finally block to commit or roll back based on a boolean flag set in the try block.
Why it's wrong here
Removing the catch block and using a boolean flag in the finally block does not log exceptions or allow specific handling. If an exception occurs before the flag is set to true, the finally block will rollback, but the exception goes unlogged, making debugging difficult. This approach lacks proper exception logging and specific catch blocks.
- ✗
Add a separate catch block for `RuntimeException` before the existing `catch (Exception e)` and call rollback there, then rethrow the exception.
Why it's wrong here
Adding a separate `catch (RuntimeException e)` block before the generic `catch (Exception e)` allows catching runtime exceptions, but the finally block still commits the transaction regardless of whether an exception occurred. Unless rollback is called inside the catch block, the transaction will commit, leading to inconsistent state. Also, this approach does not handle checked exceptions properly.
- ✓
Inside the try block, set a boolean success flag to true upon completion; in the finally block, check the flag: if false, rollback; if true, commit. Additionally, catch specific exceptions, log them, and ensure rollback logic is invoked.
Why this is correct
Using a boolean success flag in the finally block ensures that the transaction is committed only on success and rolled back on failure. Catching specific exceptions (including RuntimeException) allows logging and immediate rollback. This provides clear, robust exception handling and maintains correct transactional integrity.
- ✗
Declare the method with `throws Exception` and let the caller handle the transaction rollback.
Why it's wrong here
Declaring the method with `throws Exception` does not handle exceptions within the method; it pushes the responsibility to the caller without ensuring rollback. The caller may not roll back the transaction, leading to inconsistent state. This fails to meet the requirement of local rollback.
Visual reference
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 23, 2026
This 1Z0-811 practice question is part of Courseiva's free Oracle certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 1Z0-811 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.