4 Replies Latest reply on Dec 14, 2001 11:03 AM by Philip Van Bogaert

    Exception handling: choose your poison...

    Ignacio Newbie

      Each time you call an EJB you have to make a lookup (which can throw a NamingException), call a create/find (which can throw a CreateException and FinderException) and call the EJB method (which can throw a RemoteException/EJBException).

      That means that you have two options:
      * Option 1: Always catch(Exception) and throw it again as a RuntimeException or similar.
      * Option 2: Always catch(NamingException, CreateException, FinderException, RemoteException) and throw it again as a Runtime or similar.

      In JBoss code I have seen (ok, I honestly believe I have seen) the two alternatives applied. I can see some of the caveats with each solution. But I wanted to see the opinions of gurus out there... ?:|

        • 1. Re: Exception handling: choose your poison...
          Andreas Schaefer Apprentice

          From a client view he/she does not want to be bothered with EJB exceptions but to just convert them to RuntimeException is bad as well because the client has still to deal with it (when you got a ticket you do not put them into the waste basket and think it is solved).

          I suggest to create Client exceptions and then convert the EJB exceptions etc. to this client exceptions. If you cannot get a hold of services (NamingException) rethrow it as ServiceUnavailableException, when EJB is not found as InvalidSearchCriteriaException and so on. To make it a little bit simplier you can use attributes to reduce the number of exceptions and then let a client support class come up with a good explanation.


          • 2. Re: Exception handling: choose your poison...
            J. Wolfgang Kaltz Novice

            I like to distinguish between a 'technical exception' (NamingException, general Remote exception) which would result on the client side in something like a ServiceUnavailableException; and business exceptions. That means for the EJB business methods, define application specific, business-relevant exceptions which the client must deal with (at least because it will need to display a language-dependant meaningfull business error to the user).

            Your access to the EJBs (at least for getting the home interfaces) should be encapsulated at a single point ("ServiceLocator pattern"); so the handling of the NamingException can be centralized there.

            • 3. Re: Exception handling: choose your poison...
              Fusayuki Minamoto Apprentice

              'Business Delegate' pattern is used for translating exceptions between business and presentation tier.


              • 4. Re: Exception handling: choose your poison...
                Philip Van Bogaert Newbie


                an RemoteException for example could have security reasons (wrong username or password)

                or an entity bean could doesn't exist any more (is removed out of the database)
                NoSuchObjectException, this could be a application exception that an account is delete for a user.

                Think that none of the EJB/Remote Exceptions are real system or application exception they actually both.

                Personally i think that you must deal with an exception or die.

                i have seen to often that an exception is just catched and null is returned (very hard to find bugs).

                an errorhandler interface like xml parser use may have some benefits to.

                this is an very interesting topic (to much ignored)

                howto handle exceptions