[ 
https://issues.apache.org/jira/browse/MYFACES-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058046#comment-13058046
 ] 

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: https://issues.apache.org/jira/browse/MYFACES-3201
>             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: http://www.atlassian.com/software/jira


Reply via email to