Page 1 of 1
About Question enthuware.ocpjp.v7.2.1423 :
Posted: Tue Jul 21, 2015 11:48 am
by Danny Sheridan
I answered false to this question although aware of the abrupt completion scenario.
Here's my reasoning:
The explanation is correct for the abrupt completion of synchronized code.
But the question relates to a synchronized method which
'throws an exception in its execution'.
As
'throws out of the method' or
'an unhandled exception'
is not specified could not this just as well be a handled exception?
For example, completingMethod() completes normally here
Code: Select all
package study.ocp2;
public class SynchronizedAbruptCompletion {
public static void main(String[] args) {
completingMethod();
}
static synchronized void completingMethod() {
try {
throw new Exception();
} catch (Exception e) {
System.out.println("Handled "+ e.getClass().getName());
}
System.out.println("Further operations");
}
}
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Tue Jul 21, 2015 9:17 pm
by admin
Yes, it is possible to interpret it that way. But in the exam you may find similarly worded questions.
Also, if you think about it, in your code the method doesn't really throw any exception. The code inside the method throws an exception. When you say that a method throws an exception, it is implied that the exception is thrown out by the method.
HTH,
Paul.
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Sat Sep 05, 2015 2:20 pm
by boyonsea
Completely agree with the OP
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Mon Jan 02, 2017 3:41 pm
by jagoneye
Additional note from me would be first try understanding or reading about Locks and then read synchronization because internally synchronization does similar to
Locks
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Tue Oct 23, 2018 9:49 pm
by Mark7777
So let me get this straight. The question doesn't pertain to an exception caught and handled in the catch clause where the program might continue on? In that case, is the lock released/surrendered? That would make for complicated programming, it seems. Or, is the question limited to an exception thrown out of the method and not handled, in which case the "this" lock is released? I assumed both scenarios. When a method declares "throws Exception" it always seemed to me that the method throws the exception. Tricky language.
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Tue Oct 23, 2018 10:17 pm
by admin
>When a method declares "throws Exception" it always seemed to me that the method throws the exception.
Very sorry to say this but I do not expect this statement from an OCPJP aspirant, given that they have already cleared the OCAJP! Just think about it for a second that if this were the case, why would anyone write any code inside a method that has a throws clause? The only statement in such a method would be "throw new <the_exception_mentioned_in_declaration>;".
The throws clause in a method declaration only means that the method MAY throw that exception to the caller. The purpose of the declaration is to make the caller aware of this possibility so that it can prepare itself to take appropriate action.
If you look at the question from this perspective, you will see that the question is actually quite clear and not tricky at all.
HTH,
Paul.
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Tue Oct 23, 2018 11:37 pm
by Mark7777
Thanks, Paul. That makes sense.
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Thu Nov 15, 2018 12:23 pm
by maderkse
Hi,
I answered false... The question says "the lock acquired by the method". But shouldn't that be "the lock acquired by the current Thread"?
Regards,
Maarten
Re: About Question enthuware.ocpjp.v7.2.1423 :
Posted: Thu Nov 15, 2018 8:58 pm
by admin
Actually, locks are always acquired by threads but the problem statement is quite clear that it is talking about the lock associated with a method due to the method being synchronized. Also, a thread may have acquired other locks but those locks are not released.
I have updated the problem statement to make it more clear.
thank you for your feedback!