Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

What do you think about my Exception handling ?  RSS feed

 
Hussein Baghdadi
clojure forum advocate
Bartender
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 :

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

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
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sounds fine to me. But your findPlayer() method is throwing exception and not declared as "throws EJBException".
 
Mattias Arthursson
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!