Hi Andy,
I totally agree - and I argued like this from the beginning. There is
really no valid reason at all why the exception handler should see an
AbortProcessingException, which is just another way of saying "stop
the chain, I don't want my successors to be processed" (due to
whatever reasons, certainly not exceptional ones).
best regards,
Martin
On 5/16/12, Andy Schwartz <andy.schwartz_at_oracle.com> wrote:
> On 5/16/12 12:21 PM, Edward Burns wrote:
>>>>>>> On Thu, 26 Apr 2012 12:15:36 -0400, Andy
>>>>>>> Schwartz<andy.schwartz_at_oracle.com> said:
>> - Remove the statement "If that fails for any reason, throw an
>> AbortProcessingException, including the cause of the failure," from
>> the spec for processValueChange and processAction.
>>
>> The implementation work for this is still pending.
>>
>> Andy, can you please confirm that this is an acceptable resolution.
>
> Perfect, thanks Ed!
>
> BTW, while looking into this, I came across the following spec
> complexity (section 6.2.1):
>
>> For each ExceptionEvent in the list, call its getContext() method and
>> call getException() on the returned result. Upon encountering the
>> first such Exception that is not an instance of
>> javax.faces.event.AbortProcessingException, the corresponding
>> ExceptionEvent must be set so that a subsequent call to
>> getHandledExceptionEvent() or getHandledExceptionEvents() returns that
>> ExceptionEvent instance.
>
> Which raises the question: why are AbortProcessingExceptions passed to
> the ExceptionHandler? Shouldn't these be treated like other "expected"
> exceptions - ie. shouldn't AbortProcessingException appear in the list
> of expected exceptions at the top of section 6.2?
>
> Andy
>
>> Thanks,
>>
>> Ed
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces