Error handling

Overview of error handling

When the client calls the server, there is always the possibility of an error. For example, the network or server might be temporarily down, or the user's session might have expired. In a typical web application, where the entire contents of the window is replaced, any error would be displayed by the browser. However, for an AJAX application such as PolicyCenter, the client is responsible for handling and displaying the error.

The PolicyCenter client has basic error handling built in. For example, if the call to the server times out, it displays an appropriate and localized message. You can also add your own custom error handlers.

Add custom error handlers

Add your own custom error handlers using the gw.api.addServerErrorHandler API. The argument to addServerErrorHandler must be a function, which takes the following arguments:
  • The jQuery request object that was sent. The status field of this object contains the HTTP response code, if any.
  • The response received from the server, or null if no response was received.
  • One of the following error category numbers:
    Error category number Description
    1 Unexpected response. The server returned data, but it did not match what the client expected, and the client could not update the page.
    2 Logout (secondary requests only). The server session has expired. Normally the client redirects to the login page if the session has expired. However, if the session expires during a secondary request, then the error handler is called with this error category.
    3 Displayable error (secondary requests only). The server has returned a response that contains a displayable error message, which can be found in response.exceptionText
    4 Fatal error. If this is an HTTP error, then the status field of the request object contains the error code. This could also be an error so serious that no useful information could be provided.
    5 Timeout. The client timed out waiting for the server to respond. The timeout is configurable using the WebUIAJAXTimeout configuration parameter.
  • An error message, or null.

If the function returns true, then the client assumes that the error has been handled, and it does not call the standard built-in error handlers.

Remove a custom error handler

Remove a custom error handler by calling gw.api.removeServerErrorHandler and passing the error handler function as the argument.

Secondary requests

Secondary requests are special server requests used for very targeted purposes - for example, building a list of autocomplete suggestions, fetching an on demand menu or handling reflection. These requests are handled specially because they do not go through the usual Pebbles life cycle and cannot access some of the default behaviors (for example, updating the standard error message widget, or causing a logout redirect) that are built into that cycle.