Throwing the right Exception/Error

Discussions

EJB programming & troubleshooting: Throwing the right Exception/Error

  1. Throwing the right Exception/Error (3 messages)


    Hi,
    V are planning to catch Errors in our beans and throw an
    EJBException to the Client.The EJBException will take an Error code(String Object) as a parameter.
    At the client v will catch RemoteException and extract the error code and display a more user friendly message to the user.
    Thus the only objective of ours is a more user friendly message in case of Errors being escalated to the Web Tier.
    My doubt is that by catching an Error and Throwing an EJBException, are v loosing out on something?
    Thanks,
    Sanjay
  2. When you say Error do you mean subclasses of java.lang.Error? You shouldn't use these classes as part of your own exception tree, they are really only for things that are likely to kill the JVM.

    One option you could use is a composite pattern.

    public class ChainedException extends Exception {

      Exception e;
      int errorCode;

      public ChainedException(Exception e, int errorCode) {
        this.e = e;
        this.errorCode = errorCode;
      }

      public void printStackTrace(OutputStream os) {
        if (e!=null) {
          e.printStackTrace(os);
        } else {
          super.printStackTrace(os);
        }
      }

      public String toString() {
        return "Chained Exception, with error code " + errorCode + ": " + (e!=null) : e.toString() ? super.toString();
      }

    }


    That lets you encapsulate an exception inside another one, thus reducing the exception signature of your EJB methods. But since it over-rides all the printStackTrace(...) methods (only one shown above) you will always get the real stack trace when you dump it to the log.

    So, your bean could....


    try {
      // Do things with a database.
    } catch (SQLException sqle) {
      throw new ChainedException(sqle, sqle.getErrorCode());
    }

    .. which would work. You could also handle the error code logic yourself, in which case, write a helper class to encapsulate the decision about the error message and error codes.

    Hope that helps

    Chz

    Tony
  3. Hi Tony,
    Thanks for the information.
    Guess i have not been too lucid so here goes.
    V have a framework in place for handling application level exceptions that is akin to the example u have given.
    V have this little concern which is in points below:

    1.Ours is a product and our objective is to provide the end user with as user friendly messages as possible.

    2. In case the Application server throws an error as in java.lang.Error then the message that the end user gets may not make much sense to him/her

    3. So our solution is, in our bean methods v will have a try -catch block as below

    X()throws abcException
    {
    try{

       //business Logic
       }
    catch(Error e)
    {
    //Log the error
    throw new EJBException("ERRCODE");
    }
    Now at the client say a JSP, v will catch RemoteException ie
    App server will throw RemoteException and then v will extract the ERRCODE and by getting the Corresponding err message from a property file(say!) display a message (say) as below:
    There is some problem in processing ur form.Pls try later

    Thus what v r getting is clarity for the end user and what v r loosing out on is good design. So is this right?
  4. I wouldn't do that, personally.

    I wouldn't catch it in the beans. Have a standard error page for all JSPs. When unexpected errors happen, you can display the helpful information in there.

    I can see why you want error codes, particularly for help desks and the like.

    On the other hand, you don't want to give too much information to end users, it can give hackers too much information when they are trying to blow your site up.

    Most of the JSP engines will log the exception for you anyway.

    Chz

    Tony