ejb exception questions

[Walter Vetrivel]

An EJB business method performs an operation that throws a checked exception. The bean cannot recover from this checked exception and should rollback. The bean will be deployed using container-managed transaction demarcation. Which implementation is the BEST?





a) public void businessMethod() { try { // operation throwing SomeCheckedException goes here } catch (SomeCheckedException ae) { throw new EJBException(ae); } }

b) public void businessMethod() { try { // operation throwing SomeCheckedException goes here } catch (SomeCheckedException ae) { context.setRollbackOnly(); throw new EJBException(ae); } }

c) public void businessMethod() throws EJBException { try { // operation throwing SomeCheckedException goes here } catch (SomeCheckedException ae) { throw new EJBException(ae); } }

d) public void businessMethod() throws EJBException { try { // operation throwing SomeCheckedException goes here } catch (SomeCheckedException ae) { context.setRollbackOnly(); throw new EJBException(ae); } } }


Single Select - Please select the best answer (one and only one choice must be selected).

[Amanda Waite]

I seem to remember this question from the IBM exam. I also seem to remember answering 'd' after some investigation. Although I can not remember my reasoning at the moment.
Amanda

[Vivek Viswanathan]

Hi
I would have gone with option 'd', I need more information about the IBM exam
Vivek

[Vishakha Ahuja]

I was under the impression that you can handle an exception either with the "throws clause" or enclosing it in "try-catch block".
Can someone explain why choice "b" would be wrong ?

[Jaspreet Singh UK]

A seems right to me ..
Do you need to declare you are thowing an EJBException?
Also when you thow a EJBException you will automatically cause a rollback in CMT so there is no need to call setRollbackOnly().
J

[Asif Ali]

Answer A is correct.
EJBException is a checked exception, so answers C & D are not valid since you do not declare a checked exception to be thrown. Answer B is incorrect since context.setRollbackOnly() is required for application exceptions where the transaction must be rolled back (the method is catching a checked exception). Answer A is correct since any runtime exception (and subclasses of) will be propogated to the container, which will then invalidate the transaction.
AA

[Walter Vetrivel]

The url for the IBM test is http://certify.torolab.ibm.com/.
A lot of the questions looked vague to me but then I am just preparing
for the scea.
I think maybe Amanda who has already taken a test can tell us she came up with such questions in the scea.
Any help will be appreciated as we all would benefit by knowing what to learn and what not to, rather than barking up the wrong tree!!!

[Rahul Mahindrakar]

i just wanted to check up the fact that you do not need to use throws for runtime exception. Only a checked exception needs to use throws

class  abc
{
//public static void main(String[] args)  throws xyz
    // IS THE ABOVE THROWS REQUIRED FOR A CLASS THAT EXTENDS RUNTIME EXCEPTION ??? No is the answer
    public static void main(String[] args) 
{
System.out.println("Hello World!");
        throw new xyz();
}
    public void main1() throws def{
   // yes i need a throws for def as it extends Exception        
        throw new def();
    }
}
class xyz extends RuntimeException
{
};
class def extends Exception
{
};

I think the answer is a.
Reason.
An EJBException thrown and caught by the containar automatically rolls back the transaction so b and d are out of the contest.
Coming to c, you do not need to use throws for a RuntimeException like EJBException as in the code given above.
So "A" is correct.
------------------
Regds.
Mahindrakar

[John Wetherbie]

I think it is A or B because as stated above EJBException is derived from RuntimeException, so you don't need the throws clause. Additionally, it is stated that rollback must occur. If you don't call setRollbackOnly then it is possible, depending on the transaction type and which entity (container or bean) initiated the transaction, for the container to attempt to commit the transaction.
I'd go with A as Asif stated above.
I'm using chapter 8, specifically table 8-3, from Enterprise JavaBeans (2nd Ed.) by Monson-Haefel as my reference.
John
[This message has been edited by John Wetherbie (edited April 25, 2001).]

[Vivek Viswanathan]

Hi
I was almost going in for option 'd', but after having another look at the EJB 1.1 Specification, I am going with option 'a'
You can clarify it at
EJB Spec 1.1 page 189 , under the section '12.2.2 System Exceptions'

[David Harkness]

This is why I don't like standardized tests like this. True, answer A is technically correct, but I would *never* do this in real code. Throwing EJBException *on purpose* is weak, especially when the lower level method is throwing a meaningful application exception already. I'd do the following in a real project.

public void businessMethod ( )
throws SomeCheckedException
{
    try {
        // code that throws SomeCheckedException
    }
    catch ( SomeCheckedException ae ) {
        context.setRollbackOnly();
        throw ae;
    }
}

Yes, throwing EJBException tells the container to do the rollback for you (saving a line of code, whoopie), but you then have to catch EJBException and dig into it to figure out what happened. You lose the nice exception handling logic of Java by stuffing your application exceptions down into EJBException.
My 2 cents.

[Billy Tsai]

I dont think there are any EJB exception questions in SCEA part1, I didnt see any questions on exceptions when I took 310051.