Most web application development frameworks leave the handling of exceptions up to the developer. WebRocketX has the clean handling of both server generated and network based exceptions built in from the start.
- Exception Handling
Using the errorPage Attribute To Elegantly Handle Server Side Exceptions
Shown below is a meta capsule marked with the errorPage attribute. This attribute
tells the WebRocketX framework that this content was produced by a server side
exception and that the developer's successful callback should be skipped
and instead the developer's failure callback should be called (failure callbacks
are rarely needed actually). The contents
of the capsule will still be displayed according to the capsule type. So, the developer
is free to display server side exceptions anyway they choose. In this case,
the exception is being displayed as a modal popup. The divs wrapping the table
are stylings that float and center the content.
The errorPage attribute could have also been combined with a capsuleType of "inline" and maybe a message to call support could have been displayed in the header every time. Another option is the errorPage attribute could have been combined with a capsuleType of "data" and a jsOnload could have been used to execute some browser side logic. The clearing of a server side error message written to the header is usually done when the user navigates to other parts of the application. The globally defined dtNavigationCallback function can be overridden by the developer to do this. See the Calling The API page for more details.
Example of a Server Side Exception Formatted As A Modal Popup
Recommendations For Centralizing The Handling Of Server Side Exceptions
Web application frameworks such as Spring, Struts, and JSF already provide mechanisms for channeling all unhandled server side exceptions to a single page. When using WebRocketX this page should be one rendering our capsule marked with the errorPage attribute. Often the content inside this capsule will contain a toll free number for the user to call for support along with an error number that support can look up in their server logs. It is a good idea to branch the logic of your error page to behave differently in development and QA vs. production. In a non-production environment it is nice to have a full stack trace displayed so that tracking down errors can be done efficiently.
Handling Communication Errors
Communication errors are caused when either the browser cannot successfully communicate
with server or receives a response it cannot understand. Since the server cannot be reliably
reached, WebRocketX solves this problem by requiring a specialized modal dialog layout be present
in the welcome page of the SPA application. For more details on this go to the
part of this tutorial. Below are listed the most common communication errors that can occur. The will
all be handled automatically by WebRocketX as long as the communication error modal dialog is formatted correctly.
Metacapsule missing - The framework could not find the Metacapsule in the content returned from the server. This is actually a very
powerful mechanism because many modes of failure on the internet return a blank page or a garbled response,
and by expecting a predictable format the WebRocketX
framework will not:
- Mysteriously "do nothing"
- Display a bunch of weird symbols in your web page
Async call timed out - The call took too long to come back and the browser gave up on it.
HTTP Error Codes - Any call that resulted in a code other than 200 or 202, which are both types of successful.
Handling Session Timeouts