Abusing Swift’s Result Type

A Tale About When the Result Type Shouldn’t Be Used

Photo by Mike Kilcoyne on Unsplash

When the Result type was added to Swift’s standard library a few years ago, this simple change affected how we treat completion-based asynchronous methods enormously. Judge for yourself: the clumsy and ambiguous completion handlers like the one below sank into oblivion.

func getData(_ completionHandler: (_ data: Data?, _ error: Error?) -> Void)

In case someone doesn’t fully understand the ugliness of the method presented above, no, the problem is not (only) in multiple arguments of the closure. The main issue is the arguments’ nullability: every time, you have to check both of them in order to determine whether the call succeeded or failed. In other words, what if both of them are nil? Or even worse, both are not nil?

Not a member? Read here for free.

Result solves the problem rather elegantly:

func getData(_ completionHandler: (_ result: Result<Data, Error>) -> Void)

So, instead of this mess:

getData { data, error in
    if let error {
        // Handle the error.
    }
    if let data {
        // Use the data.
    }
    // Handle the probably impossible case of both error and data being nil.
}