Hi Ed -
On 2/6/14 4:14 PM, Edward Burns wrote:
> If #{bean.throwExceptionOnAjax} throws an exception? What should happen
> to the handleError()? It should get invoked, right?
>
Sure.
> Well, it doesn't. Instead, we get an exception about nested CDATA.
>
> That's the first problem.
>
> Once we fix the nested CDATA problem, we now see that the error handler
> is not invoked because the status is not set to 500.
>
> Here are my questions to the community.
>
> Should an exception occurring during render cause an HTTP 500 error to
> be set as the status of the Ajax response?
>
Would that require buffering up the entire response just in case we end
up needing to call sendError(500)? If so, I would rather that we not do
this.
> Should we allow the ajax error handler to take effect when the rendering
> contains broken CDATA rendered response text?
>
Seems reasonable.
> I have a patch that makes it so both of things are true.
>
How do you set the response status code after rendering has started?
> Here is the partial Ajax response with the proposed fix in place:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <partial-response id="j_id1">
> <changes>
> <update id="willThrowException">
> <![CDATA[
> <partial-response id="j_id1">
>
This would be something like "<span id="j_id1">" as opposed to a nested
<partial-response> element, right?
> ]]>
> </update>
> </changes>
> <error>
> <error-name>class java.lang.RuntimeException</error-name>
> <error-message>
> <![CDATA[
> Intentionally throwing exception on ajax request
> ]]>
> </error-message>
> </error>
> </partial-response>
>
> Is this ok?
>
Sounds fine. Does the xsd for partial response payloads allow this?
Would we attempt to apply the <changes> if an <error> is present later
on in the payload?
If the <changes> content contains invalid content (cannot be parsed), do
we call the error handler? If yes, does the error handler get called
twice (once for the invalid <changes> content and again for the <error>)?
Andy
> Ed
>
>