myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kočí (JIRA) <>
Subject [jira] [Commented] (MYFACES-3201) Publish exception in lifecycle methods (process*) instead of re-thrown
Date Thu, 30 Jun 2011 20:07:28 GMT


Martin Kočí commented on MYFACES-3201:

Please notice that proposed new behaviour does not change process flow for user of myfaces:
default exception handling stop execution of next phases and outputs error page. Only change
is that now all queued exceptions are reported with error page, not only the first occurred.

> Publish exception in lifecycle methods (process*) instead of re-thrown
> ----------------------------------------------------------------------
>                 Key: MYFACES-3201
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Sub-task
>          Components: General
>            Reporter: Martin Kočí
> Requirement: "user should see not just a cryptic stack  trace, but also the component
 that   triggered the problem"
> Problem in current code is that first exception breaks current phase and exception in
queued without component info.
> I think that every lifecycle method (processDecodes, processValidator etc.) should try
catch every exception and publish it for later processing with exception handler.
> Spec does not says it directly but we can find:
> "The exception must not be re-thrown. This enables tree traversal to continue for this
lifecycle phase, as in all the other lifecycle phases" from UIInput.updateModel
> "ExceptionHandler is the central point for handling unexpected Exceptions that are thrown
during the Faces lifecycle" from ExceptionHandler javadoc
> process* method can silently "do nothing" : UIInput.updateModel does it already.
> Publishing event allows handle multiple problem at once: consider buggy validators/converters
-> create more than one exception in queue and coder can see them at once.
> The main parameter of ExceptionQueuedContext is UIComponent and the best place where
component is always known is component itself.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message