iOS Handling Errors
Networking iPhones with other systems under the implied assumption that things just work. In this article you discard that assumption and dive into the real world of networking. In this real world, things go wrong, sometimes extremely wrong: Phones move on and off networks; packets get lost or delayed; network infrastructure fails; and there is the occasional user error. Writing a networked iOS app would be much easier if things just worked, but unfortunately that isn't the case. This article reviews some of the things that can cause networked operations to fail. It discusses how the system informs the app of the failure, and how the app should gracefully inform the user. A software pattern that is helpful in handling errors in a clean and consistent manner without requiring error handling code in the application logic is also described.
Understanding Error Sources
In the early days of iOS there was a weather app from a reputable source. It worked well on Wi-Fi or a clean cellular network, but if the network was anything less than perfect, this weather app seemed to catch a cold and crash to the Home screen. Dozens of other apps respond poorly to network errors with a blizzard of UIAlertViews frantically informing the user that there is a "404 Error on Server X" or something similar. Other apps have interfaces that become unresponsive if the network is slow. Each of these is an example of poor understanding of network failure modes and anticipation of possible network degradation or failures. If you want to avoid these kinds of errors and adequately handle networking errors, you must first understand their origin.
When you consider what a byte must do to get from a device to a remote server and back, all within a couple of hundred milliseconds, it is a miracle that networked devices work at all. The complexity of device networking and internetworking led to the development of layered networks. Layered networks divide this complex environment into more manageable chunks. Although this helps the programmer, networking errors like those mentioned previously can occur as data moves between layers.
Every layer performs some sort of error checking, which could be mathematical, logical, or something else altogether. For example, when the network interface layer receives a frame, it fi rst validates the contents against the error correcting code, and if it doesn't match, an error occurs. If the frame never even arrives, a timeout or connection reset may occur. Error checks occur at every step up the stack on the way to the application layer, where the message is checked both syntactically and semantically.
Although there is an almost infi nite number of ways that a connection between a phone and a server may fail, when using the URL loading system in iOS, you can group these causes into three categories of errors: operating system errors, HTTP errors, and application errors. These categories of errors correlate to steps in the sequence of operations necessary to make an HTTP request. HTTP request to an application server to provide some data from an enterprise network. Each of the shaded zones represents an error domain for each of the three types of errors. Typically, operating system errors are caused by problems reaching the HTTP server. HTTP errors are caused by problems within the HTTP server or application server. Application errors are caused by problems with either the data delivered in the request or with any other systems the application server queries.
The steps in the sequence become much more complicated if the request is a secure HTTPS request or if the HTTP server redirects the client. For many of these steps, there are numerous substeps, such as the sequence of SYN and SYN-ACK packets involved in establishing a TCP connection. The following sections describe each error category in greater detail.
