HTML and CSS Reference
In-Depth Information
Chapter 6. Error
Handling
and
Fallbacks
By now, you must be familiar with the WebSocket capabilities and must have got an
idea of the power of full-duplex communication. However, the WebSocket goodies are
built on top of HTML5 and depend strongly on the browsers for full support. What hap-
pens when the features you want to implement are not supported by the means your
audience is using? Would you let your customers leave? That doesn't sound like a
good idea. Fortunately, with a little bit of extra effort, you can implement, mimic, and
mostly emulate, the WebSocket behavior.
WebSocket is the future-friendly way to go, but you'll need some fallback techniques
in order to support the widest audience possible.
Error handling
When it comes to error handling, you have to take both internal and external paramet-
ers into account. Internal parameters include errors that can be generated because of
the bugs in your code, or an unexpected user behavior. External errors have nothing
to do with the application; rather, they are related to parameters you have no control
on. The most important one is the network connectivity. Any interactive bidirectional
web application requires, well, an active Internet connection.
Checking network availability
Imagine that your users are enjoying your web app, when suddenly the network con-
nection becomes unresponsive in the middle of their task. In modern native desktop
and mobile applications, it is a common task to check for network availability. The
most common way of doing so is simply making an HTTP request to a website that
is supposed to be up (for example, http://www.google.com ) . If the request succeeds,
the desktop or mobile device knows there is active connectivity.
Similarly, HTML has XMLHttpRequest for determining network availability. HTML5,
though, made it even easier and introduced a way to check whether the browser can
accept web responses. This is achieved via the navigator object:
Search WWH ::




Custom Search