You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Martin Kočí (Commented JIRA)" <de...@myfaces.apache.org> on 2012/03/19 21:25:38 UTC
[jira] [Commented] (MYFACES-3201) Publish exception in lifecycle
methods (process*) instead of re-thrown
[ https://issues.apache.org/jira/browse/MYFACES-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232866#comment-13232866 ]
Martin Kočí commented on MYFACES-3201:
--------------------------------------
Proposition:
* because we need to queue component and other suitable infos in places where exception occured : try - catch every signitificant method on UIComponent and publish exception context
* rethrow the exception to break current phase
* ignore the second attempt to queue the same exception
in pseudo code:
UIComponent.processSomething:
try {
} catch (RuntimeException e) {
context.publishExceptionAndComponentAndOtherInfos
throw e; // will break this phase and causes context.renderResponse()
}
and in LifecycleImpl:
try {
lifecycle.process
} catch (Exception e) // this one is the same as in previous UIComponent code
{
context.publishExceptionButIgnoreIfAlreadyQueued
}
the re-throw of the exception is needed because current phase must be stopped. No UIComponent methods have a return value to indicate that processing has failed - we must use an Exception to provide that.
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira