Here is my opinion: the purpose of AbortProcessingException is similar as ValidatorException or ConverterException. These are thrown as a result of normal lifecycle processing.
With AbortProcessingExpcetion it is (or should be) possible to achieve this: <h:commandButton> <f:actionListener ...> <!-- may throw a exception - if it does it will be queued for exception handling; but broadcasting continues --> <f:actionListener ...> <!-- This one throws AbortProcessingExpcetion --> <f:actionListener ...> <!-- not executed if previous throws AbortProcessingExpcetion; but independent from the first one --> </h:commandButton> That is a classic isolation of listeners in observer pattern. Where is the problem? Specification works with APE inconsistently. First it says that APE must be propagated to ExceptionHandler: "All other Exception cases must not be swallowed, and must be allowed to flow up to the Lifecycle.execute" (6.2 ExceptionHandler) but continues in "6.2.1 Default ExceptionHandler implementation: Upon encountering the first such Exception that is NOT an instance of javax.faces.event.AbortProcessingException". So - APE is queued but ignored in exception handler! Spec says that APE "the Exception must be logged and not re-thrown." - but why propagate APE to exception handler if the only result is log? Secondly, Application.publishEvent - "If the act of invoking the processListener method causes an AbortProcessingException to be thrown, processing of the listeners must be aborted, no further processing of the listeners for this event must take place, and the exception must be logged with Level.SEVERE" - no words about exception handler. And third problem is described as MYFACES-3199. My proposition is to work with APE as follows (if TCK allows it): 1) AbortProcessingException is 'expected' exception and users can throw it from listener in same manner as they can throw ConverterExpcetion from converters and ValidatorException from validators 2) Isolate listeners and work with APE with algorithm suggested in MYFACES-3199 3) Unify working with APE in myfaces code: we can introduce new param "rethrowEveryListenerExceptionAsAPE" to preserve current behaviour. Martin Koci píše v Čt 07. 07. 2011 v 14:10 +0200: > Hi, > > > what is purpose of AbortProcessingException in JSF API? > > Please see https://issues.apache.org/jira/browse/MYFACES-3199 > Currently specification and myfaces work with it unconsistently. > > Do you have example of usage in your JSF applications? > > > Regards, > > Kočičák > > > >
