1Z0-811 Exception Handling and Development Tools Practice Question
A developer is maintaining a Java backend service for order processing. The service uses a third-party library that throws a checked PaymentException when a payment fails. The current processOrder method catches Exception generically, logs the error, and returns null. The business requires that when a payment fails, the order status must be updated to 'FAILED' in the database, and a notification must be sent to the customer. However, due to the generic catch, these actions are not performed. The developer must modify the code to meet the business requirements without changing the external API of the class (i.e., the method signature must remain the same and must not throw any exceptions to the caller). Which course of action should the developer take?
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
✓
In the catch block, check if the exception is an instance of PaymentException, then update the order status and send notification. Do not rethrow the exception.
The correct approach is Option D. The current code catches Exception generically, which prevents the specific handling of PaymentException. Option D catches Exception, checks if it is an instance of PaymentException, updates the order status and sends notification, and then does not rethrow the exception. This satisfies the business requirements without changing the method signature or propagating any exception to the caller. Option A is incorrect because rethrowing a RuntimeException still propagates an exception. Option B is incorrect because declaring throws Exception propagates the checked exception. Option C is incorrect because a finally block would execute even on success, leading to incorrect notifications and status updates.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Catch PaymentException specifically, update the order status and send notification, then throw a new RuntimeException to indicate failure.
Why it's wrong here
Throwing a RuntimeException propagates the exception to the caller, which violates the requirement that the method must not throw any exceptions.
- ✗
Remove the try-catch block and declare the method with throws Exception, allowing the caller to handle payment failures.
Why it's wrong here
Declaring throws Exception changes the method signature and propagates the exception, violating the requirement.
- ✗
Use a finally block to update the order status and send notification regardless of success or failure.
Why it's wrong here
A finally block executes even when no exception occurs, so it would incorrectly update status and send notification for successful payments.
- ✓
In the catch block, check if the exception is an instance of PaymentException, then update the order status and send notification. Do not rethrow the exception.
Why this is correct
This handles the specific exception, performs required actions, and does not propagate any exception, meeting all requirements.
Go deeper
Related to this question
About these practice questions
One of 481 original 1Z0-811 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.