X

An Oracle blog about Java Technology

GlassFish v2 - Post your Ideas on Improved Usability and Error Messages

Guest Author



Photo of Robot B9

We are planning a kick-off for GlassFish v2 mid-to-late July.
One of the themes will be
>Increased Productivity through Improved Error Messages
and we would welcome ideas and requests you may have in that topic.
You can post ideas or requests as comments here,
or in the
GlassFish Forum.

Pictured is Robot B9, from the
Original Lost in Space TV Series,
with its famous, but not very detailed, warning message:
Danger, Will Robinson!.


Community, Productivity, Adoption, ErrorMessages,

Join the discussion

Comments ( 2 )
  • Cay Horstmann Monday, July 3, 2006
    I have a whole bunch of bad scenarios at http://www.horstmann.com/elvis/hated-error-messages.html. A couple of the JSF issues have been fixed recently, but there is still plenty of work left to do.
  • Cheng Fang Saturday, July 8, 2006
    Cay, great summary. A few comments on "Nested exception is..." section.
    When a system exceptin (e.g. NPE in your case) occurred in EJB, the container is required to log it and rethrow a EJBException. This is the nature of any distributed computing. Users really need to look at both client side errors and server side logs. From the client side error (e.g., RemoteException, ServerException, etc), users can know the root cause is at the server side. I'd suggest appclient container print out something like: "please refer to server.log for server-side errors..."
    I feel the same pain every time I see the long stacktrace from appclient container for any errors. They are not well ordered. Normally people would expect the outer-most exceptions first, and the inner-most exceptions last. But from the appclent exceptions I've got, it's hard to tell which one wraps which.
    It seems all these appclient exceptions are chained like this, from outer-most to inner-most:
    1. java.lang.RuntimeException
    2. java.lang.reflect.InvocationTargetException
    3. javax.ejb.EJBException
    4. java.rmi.ServerException
    5. java.rmi.RemoteException
    A general suggestion on logging wrapper exceptions like InvocationTargetException and PrivilegedActionException. IMHO, It adds no value to log them. Just logging their getCause() should be sufficient. Why would a user care if you are using reflection, or doPriv block? These exceptions only expose implementation details, and clutter logs.
    For the same reason, I wouldn't rethrow a InvocationTargetException and PrivilegedActionException to the client (caller) code. But I'm less sure about this since appserver is very complex software.
    Just my 2 cents.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.