Originally posted by Andrew Perepelytsya:
I guess, java.io.IOException can be thrown even in this scenario. Beans have a permission to read properties, and this operation throws the exception. Though, returning it to the client is not a good practice.
Can someone confirm?
Which of these are correct?
A) javax.transaction.TransactionRolledBackException is a RemoteException.
But TransactionRolledbackLocalException is an EJBException which is RuntimeException
B) javax.transaction.TransactionRequiredException is an application exception.
Its again a RemoteException
C) the ObjectNotFoundException is an application exception.
False, its a FinderException
D) the NoSuchEntityException is an application exception.
Nope , its an EJBException
E) A multi-row finder method in an entity bean must throw a FinderException if no entities were found.
True, I guess
F) Application exceptions are converted into RemoteExceptions before being thrown to the client.
False, they are not changed
G) Application exceptions do not automatically result in a rollback of a transaction.
H) System exceptions do not automatically result in a rollback of a transaction.
OK, there you go.
Originally posted by Dennis Shi:
a, c, g
public class ObjectNotFoundException
The ObjectNotFoundException exception is thrown by a finder method to indicate that the specified EJB object does not exist.
Only the finder methods that are declared to return a single EJB object use this exception. This exception should not be thrown by finder methods that return a collection of EJB objects (they should return an empty collection instead).
Which one can be defined as an application exception?
The answer is C. Concluded from the discussion below. June 05, 2003
[ June 05, 2003: Message edited by: ZheMin Lin ]
Just the other day, I was thinking ... about this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton