[
https://issues.apache.org/jira/browse/MYFACES-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065492#comment-13065492
]
Martin Kočí commented on MYFACES-3201:
--------------------------------------
1) UIComponent mandates only for processDecode: "If a RuntimeException is
thrown during decode processing, call FacesContext#renderResponse} and
re-throw the exception"
UIInput says the same ("If RuntimeException is thrown during .. and re-throw
the exception") for:
2) UIInput.processValidators- "If a RuntimeException is thrown during
validation processing, calls facesContext#renderResponse and re-throw the
exception.
3) UIInput.processUpdates -"if a RuntimeException is thrown during update
processing, calls FacesContext#renderResponse} and re-throw the exception."
Problems:
A) no specification for exception handling for processRestoreState,
processSaveState,processEvent and encodeAll, encodeBegin,encodeChildren,
encodeEnd
B) UIInput.processUpdates includes UIInput.updateModel, but updateModel = "The
exception must not be re-thrown. This enables tree traversal to continue for
this lifecycle phase, as in all the other lifecycle phases."
By my opinion, specification for processDecode, processValidators and
processUpdates should be:
If a RuntimeException is thrown during decode (validation|update) processing,
call:
-- FacesContext#renderResponse
-- Create an ExceptionQueuedEventContext, passing the FacesContext, the
exception, this component instance, and PhaseId.XYZ to its constructor
-- call context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, eventContext);
-- do NOT re-throw the exception. This enables tree traversal to continue for
THIS lifecycle phase.
> 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
