Declarative exception handling is a very welcome feature in struts b1, but
it receives very little comments. I put my little thought here and hope it will
help when b2 is coming out:

1. The 'scope' attribute in ExceptionConfig is possibly redundant.

    According the current API doc, the 'scope' is to used to specify where
    to store the ActionErrors resulted from this exception. But with a
    careful examination of the machinery of the error handling and
    propagation in both struts and tomcat, errors or exceptions if any,
    *must* be resolved within life span of the request by either display
    error messages back to users or log error messages, or something else.
    there is almost no point to store ActionErrors in HttpSession.

2. There is a possibly missing attribute 'context relative' in ExceptionConfig
    that describes the 'path' attribute needed when constructing 
    ActionForward in ExceptionHandler.execute(...) method.

    Although the current API doc indicates that the 'path' is a context
    relative path, the implementation the ExceptionHandler.execute() method
    does not really build a context relative ActionForward. Would that be a bug?

    My thought to have a 'context relative' attribute in the ExceptionConfig is to
    enforce the developer to honor it when they are constructing the 
    ActionForward. The other benefit is for the tool users. If they see
    context relative checkbox selected, they are sure they are going to have
    the forward action behavior as expected. Otherwise, they would wonder how
    developers implement it.

3. It would be very nice that ExceptionHandler has an attribute to hold the
    reference to the ActionServlet instance.

    Chuck and I once discussed the need to access non-default resource
    bundles inside the ExceptionHandler.execute() method. In a bigger picture,
    developers may also need to access some plugins, data sources, etc,
    in the method. If the action servlet instance is set to the ExceptionHandler
    right after its creation, the problem is resolved.

The above problems are not really bugs. They could be *fixed* in subclasses,
but they'd better belong to base class things, any thoughts?

Jing
    
    

Reply via email to