[jira] [Commented] (DELTASPIKE-575) Improve "default" exception handling, especially for JSF

["Bob Mitchell (JIRA)" <ji...@apache.org>]

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

Bob Mitchell commented on DELTASPIKE-575:
-----------------------------------------

If I want to use the DeltaSpike builtin-in ExceptionToCatchEvent observer as part of my exception (instead of re-implementing it from scratch), neither of these solutions solves my issue, since it is what throws the unhandled exceptions.  The first is particularly unusable because observers are not ordered, so I cannot be sure my observer is called after the DeltaSpike observer.

One possible solution is to design the built-in observer in a way that makes it easier to "specialize" by providing protected methods to do things like choose how to respond to unhandled exceptions. 

My current workaround for this is to wrap the DeltaSpike JSF exception handler in my own exception handler that catches the thrown exceptions and does the needed handling.  I don't like this for two reasons:

1. I cannot distinguish easily between exceptions thrown because they were unhandled from exceptions thrown for other reasons.
2. I have to re-implement at least some of the functionality that should be provided by the JSF "standard" exception handler.

> 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)