Custom error handler not reflecting error code for 500

[Himanshu_Singhal]

Hi,

I've overridden the OOTB error handler and it works fine for 404 pages.

For 500 error, I've created a Throwable.jsp and inside the calling service class which internally set the response code 500 and include the page

RequestDispatcher dispatcher = request.getRequestDispatcher(path);
response.setStatus(500);
dispatcher.include(new GetRequest(request), response);
return;

Even though I'm setting the 500 error, the page returns 200. And, also, whatever be the content of error page, it's including inside loaded page which is like, it shows headers twice. I believe that 'cos of loading page already has header and another one is coming from error page which is included inside loading page.

Could you please check?

Best regards,
Himanshu Singhal

[Gaurav-Behl]

check the response from Rakesh here  how to handle 500 error

[Himanshu_Singhal]

Already checked. In my case, from the JSP, I'm invoking service and inside that, trying to include the response.
For 404, it works fine but for 500, if I go with include then it doesn't change response status or otherwise if I go with forward or sendRedirect then it throws "Response already committed".

[antoniom5495929]

Hi Himanshu,

sorry but I think that you are not using the standard way to customize the error handler.

As you can see into the docs [0], you just only need to overlay the errorhandler from default, without using a request dispatcher.

If you want, you can search also for the ACS Common which has inside some develop in order to use a custom error handler.

BTW: in your case I think that the real issue is that you are performing a dispatch so that the page is returned like a success code.

If you don't want to use the default and standard approach (even if I suggest you to use it); I think that you need to use a redirect in order to avoid this issue.

[0]Customizing Pages shown by the Error Handler

Let us know.

Thanks,

Antonio

[Himanshu_Singhal]

Since, you mentioned that it could be 'cos of dispatch that it could be returning success. But, that doesn't happen in case of 404.

[antoniom5495929]

Hi,

is the 500 a result that comes from a call to an external service?

Thanks,

Antonio

[Himanshu_Singhal]

Nope; It's something AEM internal 'cos at multiple places let's say null check is not there so it throws 500 error.

[antoniom5495929]

Hi,

If the error that you are facing is "Response already committed" you could try to change the response buffer in order to have the response not committed when you are setting the status.

Try in this way and let me know if it works.

A suggestion: don't change the value of the buffer with an high value because otherwise you can face some performance issues.

Thanks,
Antonio

[Himanshu_Singhal]

Changing the size doesn't help. And, also, tried ACS commons way - with that one also getting the "Response not committed" for 500 error.

[antoniom5495929]

Hi,

sorry, could you share with us the real message? Is it "Response not commited" or "Response already committed"?

Thanks,

Antonio

[Himanshu_Singhal]

Errata; It‘s "Response already committed"

[Himanshu_Singhal]

And, I think I understand the problem why it's not working for 500.
For the 404, since the resource doesn't exist, in that case, it doesn't make any call to any of AEM resource and hence directly jump
to error handler and render the error page (could be via include, forward or sendRedirect - all works in this case)

But, for 500, since the actual page resource exist but only let's say a component in page having some issue in backend and due to that it throws 500 error. But, before that, we have an authentication handler running which actually sets the anonymous token and cookie on the page and that could be the reason while I try to set 500 and try to do sendRedirect or forward, in that case, it shows "Response already committed".

With include, it does work 'cos in that case, it includes the error page resource inside actual rendering page and include doesn't change the status of already existing resource/page.

Kindly lemme know if the explanation makes more sense. And, considering the use case, what could be the implementation approach?

[antoniom5495929]

Hi,

I'm not sure regarding the explanation. Could you share with us the code that you are using in order to manage the error?

Let me know.

Thanks,

Antonio

[Himanshu_Singhal]

The code snippet is the same as I shared in question post. The problem is that when the component logic is invoked(the one which throws error), before that there are other components sling models are called and some of it are writing the JSON response back on page and also setting up the cookies.

Could it be the reason that it's not able to redirect and throws error "Response already committed"?

RequestDispatcher dispatcher = request.getRequestDispatcher(path);  
response.setStatus(500);  
dispatcher.forward(request, response);  
return; 

[antoniom5495929]

Hi,

let me understand, your requirement is that if a 500 is returned during the rendering of your page (e.g. for a single component) all the html request is in status 500?

I think that doesn't make sense. In that way also for a simple error you avoid the rendering of all the page.

Otherwise please try to explain your requirement because I don't understand correctly which is the expected behaviour.

Thanks,

Antonio

[Himanshu_Singhal]

Let's say in a page I've 10 components and out of which one component backend logic doesn't work as expected and throws null pointer exception. In that case, it breaks the rendering of whole page yet the page status it displays is 200 which is not okay.

So, if there's any 500 error occurs due to (I messed up situation) then in that case we'd like to show the 500 page status and display error page.

Now, to handle the exceptions I've created a Throwable.jsp and in that, return the logic which calls a service, finds out the error page specific to error code then try to forwards the request to error page. When it does, it throws error "Response already committed".

That could be because there're other components on page and corresponding to components, sling models are called and those are writing data in response. So, since response already having some data, in that case, forwarding might not be possible.

That's the scenario.