[
https://issues.apache.org/jira/browse/DELTASPIKE-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971692#comment-13971692
]
Gerhard Petracek commented on DELTASPIKE-575:
---------------------------------------------
#1 then use @Handles for ExceptionEvent (which also provides ordering via
#ordinal) or @BeforeHandles
#2 a std. jsf ExceptionHandler is no workaround (that's the jsf-api)
#3 if you are using the view-config (at least for the default-error-view), the
ViewExpiredException is handled by deltaspike already
#4 if you have any issue with the default handling, you can disable
BridgeExceptionHandlerWrapper and/or
DefaultErrorViewAwareExceptionHandlerWrapper (via config)
> Improve "default" exception handling, especially for JSF
> --------------------------------------------------------
>
> Key: DELTASPIKE-575
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-575
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core, JSF-Module
> Affects Versions: 0.6
> Environment: WebSphere 8.5
> Reporter: Bob Mitchell
>
> The default handling for exceptions is to re-throw the exception on
> completion. While this is fine in some circumstances, it may not be the best
> choice for JSF 2. The problem is that at least in my applications, I want to
> have special handling for a few common exceptions (such as JSF's
> ViewExpiredException), but in the case of a true application error or a
> resource unavailable error, I want to let the default JSF/Servlet error
> handling take over. This is particularly a problem with Ajax requests, where
> JSF's defined error handling is NOT to throw the exception back to the
> servlet container, but to create a special Ajax response containing an error
> indicator. Depending on the JSF implementation, re-throwing the exception
> may bypass that processing.
> In my mind, the best solution is to somehow allow DeltaSpike's JSF
> ExceptionHandler to request that the exception not be re-thrown by default
> and to delegate its handling to the wrapped exception handler.
> Another possibility is to provide for a "last resort" exception handler which
> can be called when the entire exception stack has been processed without the
> exception being handled. This would allow the developer to at least provide
> for their own processing for the general exception case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
