Improve Your Swift Closures with Result

Dealing with asynchronous tasks is an everyday developer task, and Swift developers mostly use closures for this type of work. Their syntax is clear and expressive, but handling a closure may be error-prone when we don’t adequately represent the results of an asynchronous operation. Result-oriented programming aims to reduce that complexity by providing a simple way to represent these results. This article will go through the basics of closures and show you how to use Result in your code.

All examples can be found in this Github repository.

Closures in Swift

Closures are self-contained blocks of code. They can be passed around and used in your code as any other object. In fact, closures have types, in the same way Int or a String are types. What makes them different is that they can have input parameters and they must provide a return type.

By default, closures don’t have any special feature which makes them asynchronous. It’s the way they are used that make them play well in asynchronous environments.

Syntax

A closure is defined by its parameters, return type and statements within it:

{ (parameters) -> (return type) in
  (statements)
}

Closure parameter types can be any Swift type. The return type can also be any Swift type. In some cases, the return type is Void and there’s no need for return statement.

Let’s take a look at how to implement a simple closure which computes the square of a number. As any regular function, you would have two parameters and one returned value.

let sumNumbers: ((Int, Int) -> Int) = { firstNumber, secondNumber -> Int in
    return firstNumber + secondNumber
}

There can be any number of statements inside the closure body, as long as the value of the return type is returned. In this case, the closure returns the sum of firstNumber and secondNumber.

Closures can be executed like any method:

sumNumbers(10,4) // returns 14

How closures work in asynchronous environment

If you look at any closure, you will see that it encapsulates a block of code. An instance of a closure can be passed around your code and executed without any knowledge of its internals. That makes them perfect for asynchronous development. A typical use case is when you specify the code that should execute upon the return of an asynchronous operation, and pass it as its parameters. The asynchronous method will do its work and execute code from your closure, no matter what it contains.

Suppose we want to carry out our computation of the square in the background, and execute some arbitrary code that can use its result. We’d pass a closure as our completion parameter:

func square(of number: Int, completion: @escaping (Int) -> Void)

As you can see square(of number: completion:) method has two parameters. The first parameter is number of type Int which is the number to be squared. The second one is a closure of type (Int) -> Void. When executing this method, the squared number result will be provided as the Int parameter in closure. The closure’s return type is Void since there’s nothing to return. And as it’ll be called after the function returns, it must be prefixed as @escaping.

Let’s take a look how this function can be implemented:

func square(of number: Int, completion: @escaping (Int) -> Void) {
    OperationQueue().addOperation {
      let squared = number * number
      OperationQueue.main.addOperation {
        completion(squared)
      }
    }
}

Inside the method body, squared is computed first in the background. After that, completion closure is called on the main thread. Since completion has Int as a first parameter, squared will be passed to that parameter.

square(of: 5, completion: { squaredNumber in
  print(squaredNumber) // Prints "25"
})

This image shows how parameters and closure return values are passed around.

Optional parameters and their problems

In some cases, the successful execution of asynchronous work may depend on various variables, such as network connectivity. In those cases, asynchronous calls need to supply information about errors that occurred. The closure also needs to provide results if the call was successful. Since there are many possible outcomes, closures define their parameters as optionals.

For example, the URLSession API defines the following method for running network requests.

func dataTask(with url: URL,
              completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask

You can see that completionHandler is a closure with three optional parameters. When working with them, you need to check which are nil and which aren’t. If Error is not nil, you need to handle the error. If it is, you need to unwrap the Data and URLResponse objects and work with them. But there’s no obvious procedure for covering all possible successful and unsuccessful cases.

Result-oriented programming

Result-oriented programming aims to fix this, by essentially replacing nil-checks in optionals with a Result<T> enum.

What’s Result<T> ?

Result<T> is how we represent the return value of an operation that has two possible outcomes: successful or unsuccessful.

This representation is very similar to the way optionals are implemented in Swift. Remember that optimonals can be in one of two states

• Contain a wrapped value – meaning that there is some value in the optional instance.
• Contain nothing – meaning that optional instance contains nothing.

If you look at how optionals are implemented in Swift, you will see that it’s actually implemented as an enum:

enum Optional<T> {
  case some(T)
  case none
}

Optional is a generic enum. This enables us to use optionals with any type, like Optional<Int> or Optional<UIView>.

Similarly, Result<T> provides two basic cases, success(T) and error(Error). T is the type defined by the result, and Error is the Swift native error definition.

Basic usage of Result<T>

A basic implementation of Result<T> enum would look like this:

enum Result<T> {
  case success(T)
  case error(Error)
}

Let’s say that you’re building software that deals with math computations. Some of them can fail, due to incorrect user input. A classic example would be attempting to divide a number by zero (which is not allowed by the fundamental rules of mathematics). So, if you were to build a division method that takes two numbers and divides them, you would have two possible outcomes. Either the division if successful and number is returned, or a division by zero occurred. By using Result<T> we can express it like this:

// Define error that can occur in the computation process
enum MathError: Error {
  case divisionWithZero
}

func divide(_ first: Double, with second: Double) -> Result<Double> {
  // Check if divisor is zero
  // If it is, return error result
  if second == 0 { return .error(MathError.divisionWithZero) }

  // Return successful result if second number
  // is not zero
  return .success(first / second)
}

To then carry out our division, we’d use a switch statement:

let divisonResult = divide(5, with: 0) 
switch divisionResult {
case let .success(value):
  print("Result of division is \(value)")
case let .error(error):
  print("error: \(error)")
}

Advanced usage of Result<T>

Result<T> enum can be easily incorporated into any development environment. To understand how to do that, we’ll use an image manipulation example.

In this example, the image located at a URL will be filtered with sepia filter and returned in closure via Result<UIImage> object. Our method signature would look like this:

func applyFilterToImage(at urlString: String, completion: @escaping ((Result<UIImage>) -> ()))

To make this process faster, we will use background queues for image downloading and filtering. This way, the application UI is not blocked by the network request. When the image downloading finishes, filtering will be dispatched to the main queue.

There are several steps involved into filtering an image with this method:

1. Create URL object from urlString parameter, so that image data can be fetched
2. Create background queue for executing network requests
3. Fetch image binary data from URL object on background queue
4. Check if fetched data can be used to create UIImage object
5. Create UIImage from fetched data
6. Create and apply filter on the main queue
7. Pass appropriate result via closure

A good implementation of this operation should cover all these steps and handle all errors that can occur:

• Url string parameter can have incorrect format
• Image fetching might fail because of networking issues
• Fetched data might not be an actual image

Example implementation

Let’s define our errors first. This example will use simple PhotoError enum to define them. Of course, you can always use errors other than the ones you have defined.

enum PhotoError: Error {
  // Invalid url string used
  case invalidURL(String)
  // Invalid data used
  case invalidData
}

After the errors, the method body is defined:

func applyFilterToImage(at urlString: String, completion: @escaping ((Result<UIImage>) -> ())) {

    // Check if `URL` object can be created from the URL string
    guard let url = URL(string: urlString) else {
        completion(.error(PhotoError.invalidURL(urlString)))
        return
    }

    // Create background queue
    let backgroundQueue = DispatchQueue.global(qos: .background)

    // Dispatch to background queue
    backgroundQueue.async {
        do {
            let data = try Data(contentsOf: url)

            // Check if `UIImage` object can be constructed with data
            guard let image = UIImage(data: data) else {
                completion(.error(PhotoError.invalidData))
                return
            }

            // Dispatch filtering to main queue
            DispatchQueue.main.async {
                // Crate sepia filter
                let filter = CIFilter(name: "CISepiaTone")!

                // Setup filter options
                let inputImage = CIImage(image: image)
                filter.setDefaults()
                filter.setValue(inputImage, forKey: kCIInputImageKey) // Set input image

                // Get filtered image
                let filteredImage = UIImage(ciImage: filter.outputImage!)

                // Return successful result
                completion(.success(filteredImage))
            }
        } catch {
            // Dispatch error completion to main queue
            DispatchQueue.main.async { completion(.error(error)) }
        }
    }
}

As you can see, methods that can throw errors are encapsulated within a do { } catch { } block. First, the URL object is created. If urlString is invalid, PhotoError.invalidURL will be returned. This pattern of error checking follows the rest of the method. If every operation was successful, a successful result with the filtered image will be returned.

Let’s say that we want to use this method on a local photo named landscape.jpeg. We create a imageURL and then execute the applyFilterToImagemethod. To check if image filtering was successful, we can use switch statement. If the result is successful, its associated UIImage object can be used as any other object.

let imageURL = Bundle.main.path(forResource: "landscape", ofType: "jpeg")!

applyFilterToImage(at: imageURL) { result in
  switch result {
  case let .success(image):
    let someImageView = UIImageView()
    someImageView.image = image
  case let .error(error):
    print(error)
  }
}

Conclusion

Result-oriented programming is an important tool for any Swift developer. It can make writing and handling asynchronous code easier and more intuitive. The idea behind it is very simple and easy to grasp, even for beginners.

Frequently Asked Questions (FAQs) about Swift Closures