one mock question for exception

[ZheMin Lin]

Which one can be defined as an application exception?
A.EJBException
B.IOException
C.RemoteException
D.NoSuchObjectException
The answer is C. Concluded from the discussion below. June 05, 2003
[ June 05, 2003: Message edited by: ZheMin Lin ]

[Ashish Sarin]

IOException in my opinion, but the Enterprise bean is now allowed to use java.io package.
regards
ashish sarin

[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?

[Dave Cronin]

That is a tricky question. Although you can't use the java.io package to access the file system, there can still be cases when IOException is thrown. It could be thrown by a bean using a client Socket for example. Also, there is probably nothing to stop a developer from explicitly throwing IOException in the bean's code.

[Sudd Ghosh]

RemoteException can become a little tricky, if one goes just by logic.
The specs says "The application exception MUST BE a subclass of java.lang.Exception but MUST NOT BE java.rmi.RemoteException."
Now java.rmi.RemoteException is also a checked exception (subclass of java.lang.Exception), so logically one can infer it to be an ApplicationException, which is INCORRECT. So one needs to memorize the exact criteria for ApplicationException.
When time is short, I try to get some logic sorted out so that the memorizing needed is less.
However, this one is creating problem in this respect.

[Karthik Guru]

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?

We used XML files, to maintain mapping between strings and commands(in the form of commandName=commandClass) in addition to other things.
This was getting read by a utility class and the session facade bean was instantiating the commands using this utility. The code that was accessing the XML file was ofcourse throwing IOException.
We were generating XML files and storing it to disk as well ( the call was ultimately executing from within the session bean method).
It often confuses me when someone says that java.io package cannot be used when coding EJBs wheareas we actually did.

[Dave Cronin]

From the EJB spec p494 it says:
"An enterprise bean must not use the java.io package to attempt to access files and directories
in the file system."
This presumably does not prevent anyone using the java.io package for I/O purpose other than accessing the file system, including the use of IOException.
It seems that using java.io for purposes such as reading XML files is a one of the EJB programming restrictions.
The RemoteException is unusual in that it is both a system exception for EJB and a checked exception in Java.

[Jane Somerfield]

d

[Kathy Sierra]

Howdy -- I think I would have to go with IOException. It can't be the other three, and you *can* use things that would throw an IOException (and use IO for non-file-system related things).
Remember, application exceptions MUST be checked exceptions, unless it is RemoteException (or one its subclasses, which is why NoSuchObjectException cannot be an application exception).
Here's another Exceptions question:
Which of these are correct?
A) javax.transaction.TransactionRolledBackException is a RemoteException.
B) javax.transaction.TransactionRequiredException is an application exception.
C) the ObjectNotFoundException is an application exception.
D) the NoSuchEntityException is an application exception.
E) A multi-row finder method in an entity bean must throw a FinderException if no entities were found.
F) Application exceptions are converted into RemoteExceptions before being thrown to the client.
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.
cheers,
Kathy

[Dennis Shi]

a, c, g

[Kalpesh Soni]

A,E,G

Which of these are correct?
A) javax.transaction.TransactionRolledBackException is a RemoteException.
True
But TransactionRolledbackLocalException is an EJBException which is RuntimeException
B) javax.transaction.TransactionRequiredException is an application exception.
False
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.
True,
H) System exceptions do not automatically result in a rollback of a transaction.
False,
OK, there you go.
cheers,
Kalpesh

OK , just to make matters worse
how many know this ?
public class java.rmi.RemoteException extends java.io.IOException

[sh yh]

Originally posted by Dennis Shi:
a, c, g

I have the same answers with yours.
Hopefully yours are right.

[ZheMin Lin]

My answer is A,C.
But I'm not very sure about choice G.
As spec says in page 376, when Bean method runs in a container-started Tx context, if instance has called setRollbackOnly, container will rollback the transaction.
Can we think it as "automatically"?

[Dave Cronin]

I would say the answers are A, C and G. I've put in some more explanations for E, F and G
E) A multi-row finder method in an entity bean must throw a FinderException if no entities were found.
False, a multi-row finder (or multi-object finder as in the spec) returns an empty collection
F) Application exceptions are converted into RemoteExceptions before being thrown to the client.
False, they are thrown back with no changes
G) Application exceptions do not automatically result in a rollback of a transaction.
True, you have to write code to call setRollbackOnly to cause a rollback. In the case of an application exception, you would have to catch the exception, and then call setRollbackOnly.

[Kalpesh Soni]

Dave
what about c ?
from j2ee API docs

public class ObjectNotFoundException
extends FinderException
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).

so how does it become an application exception ?

[Pradeep bhatt]

FinderException is an aplication Exception, so is
ObjectNotFoundException.

[Dave Cronin]

Hi Kalpesh
If you subclass an application exception, the subclass is also an application exception. ObjectNotFoundException is a subclass of FinderException, so must be an application exception. An ObjectNotFoundException is also a true FinderException according to Java subclassing rules and polymorphism.

[Dave Cronin]

FinderException is defined as an application exception in the EJB spec. However, there's an interesting article on IBM developerWorks that says sometimes you should treat a FinderException (and ObjectNotFoundException) as a system problem, and rethrow it as an EJBException.
See http://www-106.ibm.com/developerworks/java/library/j-ejbexcept.html

[pradeep arum]

a c g

[Todor Mollov]

Which one can be defined as an application exception?
A.EJBException
B.IOException
C.RemoteException
D.NoSuchObjectException
The answer is C. Concluded from the discussion below. June 05, 2003
[ June 05, 2003: Message edited by: ZheMin Lin ]

The answer is B.
RemoteException can't be in any case application exception.