Error handling when expecting a result out of an operation is a very common thing to do. For this reason, various high-level programming languages have introduced a Result type into their libraries, on top of their existing error-handling features. This feature was implemented in Swift 5.
A Result wraps a success or a failure. It is essentially an enum with two possible cases: .success and .failure. The .success case wraps the correct result of an operation, whereas a .failure wraps an Error. Its implementation uses generics, so you always know what you are going to get back.
If you have been programming for Apple platforms for a while, chances are you have seen (or maybe even wrote yourself) a line of code that looks like this:
Whether you wrote it yourself or someone else did it, one thing is clear: This is not a safe way to build URLs. Can you know, for sure, that your URL is actually valid? Intuitively, all of us can see a URL and see if it’s valid, but there is a whole lot of governing in the URL format that at some point we may find funny URLs that look valid and aren’t, or the other way around; they look invalid, but aren’t.
When we are working with apps on iOS, iPadOS, macOS, watchOS, or TVOS, it’s possible that at some point we will have to store and retrieve a lot of temporary data throughout the lifecycle of our software. Depending on our needs, we may need to cache data on disk and manually manage it ourselves, or we may only need it to cache it in memory. In the case of the latter, Apple offers NSCache, a mutable collection that lets us cache files in memory using key-value pairs.
The original title for this article was posted on my old website in 2012 and it was titled “Multithreading on iOS And Mac OS X Using NSOperations”. The original examples were written in Objective-C. This article has been rewritten from scratch not only to give the examples in Swift, but also to improve the quality of the old article. It has been shortened, and both language and tone have been revised.
