beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <carlin.rog...@gmail.com>
Subject Re: Thoughts on handling exceptions during the endContext() for page flow ControlContainerContext in NetUI
Date Tue, 11 Apr 2006 20:20:14 GMT
Hi Rich,

Thanks for the input. Looking at the processException(), it didn't seem like
a very elegant solution once I started to look at some of the different
conditions to handle when we have an exception during an end context. I
filed a bug and checked in some code (see BEEHIVE-1097) to catch the
exceptions up front and use the FlowController handleException() method. Now
we won't fall into the Struts processException(). In the case where we're
already handling an exception that was thrown during the action execution,
we'll just log the endContext exception.

Thanks again,
Carlin

On 4/11/06, Rich Feit <richfeit@privatei.com> wrote:
>
> Hi Carlin,
>
> Sorry for the delay on this.  I think that your first proposed solution
> (fixing PageFlowRequestProcessor.processException()) is something we
> should do anyway -- I must have missed that case early on.
>
> I do also think it would be fine to catch the exceptions in
> beginContext/endContext up-front, if it doesn't twist the code there
> into knots.
>
> Hope this helps.
> Rich
>
> Carlin Rogers wrote:
> > Beehive Devs,
> >
> > I've been looking at exception handing with respect to control container
> > management and wanted to get some feedback or ideas from the dev group.
> > Sorry for the long note. Hopefully the details do not cause too much
> > confusion.
> >
> > In NetUI today, when an action is executed, the FlowController.execute()
> > method goes through the following general steps.
> >
> > - get the page flow control container and call beginContext() on the
> > ControlContainerContext.
> > - execute the beginAction, Action, afterAction code (in
> > FlowController.internalExecute ())
> >   -- call the beforeAction() callback
> >   -- execute the actual action method
> >   -- call the beforeAction() callback
> > - perform the endContext() on the page flow ControlContainerContext.
> >
> > Note, in the FlowController.internalExecute() method where we actually
> > execute the action method, we already have exception handling in place.
> If
> > an exception is thrown at this stage in the NetUI framework, we will
> catch
> > it and call the FlowController method, handleException(), to invoke user
> > code if appropriate and return a destination URI. We also set the
> exception
> > being handled in the PageFlowRequestWrapper.
> >
> > However, if an exception is thrown during the
> beginContext()/endContext() in
> > the page flow Control container management, we do not catch the
> exception
> > and run it through handleException(). Instead, the exception is caught
> in
> > the processActionPerform() method of the Struts framework, then passed
> to
> > the RequestProcessor method processException(). If there's no matching
> > exception config, processException() will throw a new ServletException
> with
> > the "root cause" exception.
> >
> > Unfortunately, when there is a user defined exception handler associated
> to
> > the exception, processException()  does not properly handle an exception
> > config for the NetUI page flow exception handler. In this case, a
> > ClassNotFoundException occurs in the Struts code when it tries to create
> an
> > ExceptionHandler from the exception config. Struts expects the handler
> > attribute of the exception element in the struts config to be a fully
> > qualified Java class name.  In NetUI we generate just the method name of
> the
> > page flow Controller exception handler. This causes the CNFE. Then, a
> > ServletException also gets thrown but doesn't wrap the root cause.
> >
> > The ServletException is eventually caught in the
> PageFlowRequestProcessor
> > (in processInternal()). We then try to run it through the NetUI
> framework
> > support in FlowController.handleException(). The exception could still
> > result in an HTTP status 500 page if an exception has already been
> handled
> > during the actual action method execution, it's not a framework
> exception,
> > or one that a developer has written a handler.
> >
> > In general, I think the above works fine as designed. The only case that
> > causes an issue is when a user has defined a NetUI exception handler for
> the
> > exception thrown during the control container context management. This
> is
> > the scenario that causes the CNFE described above. I think this one case
> may
> > cause confusion.
> >
> > One possible solution is to leave the exception handling as is but just
> > change our PageFlowRequestProcessor.processException() override to check
> if
> > the ExceptionConfig is an instance of PageFlowExceptionConfig. Then we
> could
> > try to handle the exception with FlowController.handleException(),
> rather
> > than falling into the Struts super class implementation,
> > RequestProcessor.processException(), to avoid the CNFE.
> >
> > Other thoughts? Should we explicitly try to catch exceptions in
> > FlowController.execute() when we do the beginContext/endContext rather
> than
> > let them bubble up? If so, should we just log them, or try to run them
> > through the FlowController.handleException().
> >
> > Thanks for the help. Kind regards,
> > Carlin
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message