Handling of server-side HTTP 4nn/5nn errors returning a whole HTML document in jQuery's ajax requests

user_157882 0
Viewed 4226

To the point: how would you handle a server-side HTTP 4nn/5nn errors in jQuery's ajax requests? This case concerns a JSP/Servlet webapplication at the server side. Here I am not talking about trivial runtime exceptions such as NullPointerException and so on. Assume that they're all handled perfectly. A good example of such a HTTP 4nn/5nn error is 401 unauthorized (insufficient user rights) and 500 internal server error (database down, I/O error, Errors, etc). Assume that they cannot (or should not) be caught at coding level.

Right now I have just declared an <error-page> in web.xml for those kind of errors. It basically forwards the request to a predefinied JSP/HTML error page wherein the enduser is informed that a serious error has occurred and that the user can contact xx@xx.xx for further assistance. The same page also displays the global details about the error/exception.

It works perfectly in regular HTTP requests, but how would you handle it in XMLHtttp requests using jQuery? What's the best for the user experience? To me, it would be just displaying the entire error page as if it is a normal HTTP request. I've solved it as follows:

function init() {
    $.ajaxSetup({
        error: handleXhrError
    });
}

function handleXhrError(xhr) {
    document.open();
    document.write(xhr.responseText);
    document.close();
}

Although it works perfectly, it feels to me like a hack. Replacing the entire document with the contents of the HTTP error page. But is that also the way you would follow? If not, can you maybe elaborate why not and what way you'd prefer? The only alternative I see is using JS to display some alert/message box to inform the user about the unresolveable error, but the user could dismiss it and continue with the page while that should not be possible.

error-handling servlets jsp jquery
5 Answers

You seem to want to retain a working page/application after you receive an error condition that would result in an unusable state.

I would implement a state history on the client side and revert the page to the last usable state, informing the user via a prominent in-page element what has happened.

The theory behind this is related to transactions. Typically the execution flow is:

  1. Instruct transaction manager to start a transaction
    1. Begin transaction
    2. Capture state
    3. Return control to calling code
  2. Begin operations that are part of transaction
  3. On error: instruct transaction manager to roll back transaction
    1. Return execution environment to state captured above
    2. Discard any data no longer needed (e.g. state serialization)
  4. On success: instruct transaction manager to commmit transaction
    1. Finalize operations in transaction as needed
    2. Discard any data no longer needed

I have not done serious study into transaction management in javascript. Since you state that the server-side error makes the client side unusable, perhaps there is some way to implement portions of the transaction on the server-side. It is important that you not leave things half done there more so than on the client-side.

Have you thought about doing a "pre flight check" request to try to capture these issues before the client-side application attempts to do the real work?

user_253800
Related