What do you think about my Exception handling ?

[Hussein Baghdadi]

Hey all.
I have a question about exceptions handling in J2EE applications.
I have entity beans and a session bean acts as a session facade.
take a look to the following method :

  
    public PlayerDTO findPlayer(Integer id) {
        PlayerDTO dto = null;
        try {
            LocalPlayer lp = playerHome.findByPrimaryKey(id);
            dto = new PlayerDTO(lp.getNum(), lp.getName(),lp.getTeam().getCopy());
        } catch (FinderException e) {
            logger.warning("There is no Player with number: " + id.toString());
            throw new EJBException(e);
        }
        return dto;
    }

I have created a JavaBean in order to implement business delegate pattern.
I used this bean in my web tier.

  
    public PlayerDTO findPlayer(Integer id) throws RemoteException {
        return liga.findPlayer(id);
    }

my servlet is calling the previous method (inside try/catch statement), if exception
is thrown, the servlet forwards the request to find.jsp page, this JSP page prints a message tells the user about the wrong problem.
what do you think about my exception handling mechanisim ?
can it be used in real applications ?
[ October 02, 2004: Message edited by: John Todd ]

[Adeel Ansari]

sounds fine to me. But your findPlayer() method is throwing exception and not declared as "throws EJBException".

[Mattias Arthursson]

Since EJBException is an unchecked exception it shouldn't be declared in the throws clause. For the same reason I would not throw it to indicate an error, since it makes it less transparent to anyone that implements a client what could go wrong.

It would be better to create your own Exception subclass, declare it in the throws clause and use it to indicate an error. That way you eliminate the risk that the client doesn't catch the exception.
[ October 02, 2004: Message edited by: Mattias Arthursson ]

[Adeel Ansari]

Originally posted by Mattias Arthursson:

Since EJBException is an unchecked exception it shouldn't be declared in the throws clause. For the same reason I would not throw it to indicate an error, since it makes it less transparent to anyone that implements a client what could go wrong.

It would be better to create your own Exception subclass, declare it in the throws clause and use it to indicate an error. That way you eliminate the risk that the client doesn't catch the exception.

my real means to say that is, "doesn't jhon getting any compile time error, though throwing exception in the method that is not declared as throws Exception".

And ofcourse we should wrap the exception in our custom made exceptions in order to provide user with some more understandable message and to make sure that exception would be caught.
[ October 03, 2004: Message edited by: adeel ansari ]

[David Harkness]

I think I agree with the responses so far, but I'll summarize.

My first choice would be to declare your own exception hierarchy, including an ObjectNotFoundException of some sort (one for each object type or one general one). Have it be an application exception (extends Exception -- not EJBException).

If you'd like to stick with the base exceptions, however, then there's no point in wrapping FinderException -- which extends EJBException -- in an EJBException since it already is one.

Note, though, that by throwing an EJBException, the transaction is going to be marked for rollback. That's one advantage of using an application exception in this case. It all comes down to whether or not a missing object is an unrecoverable (system) exception or an expected-though-unusual application error.

[Tomasz Luchowski]

Originally posted by David Harkness:
If you'd like to stick with the base exceptions, however, then there's no point in wrapping FinderException -- which extends EJBException -- in an EJBException since it already is one.

That's incorrect - javax.ejb.FinderException does not extend javax.ejb.EJBException - it extends java.lang.Exception, so it is a checked exception, not an unchecked (system) one.

[David Harkness]

Originally posted by Tomasz Luchowski:
That's incorrect - javax.ejb.FinderException does not extend javax.ejb.EJBException - it extends java.lang.Exception

Yikes! My bad. Thanks for the correction.

Then in that case I'd still not wrap it as you'd probably not intend to roll back every transaction that it occurs in. In other words, I still feel it's an application and caller-specific exception -- not a system exception.

Wow, I gotta lay off the Corn Pops.