Result Type in Swift

Swift 5 introduces a new Result type to handle the result of an asynchronous function using an enum.

According to Apple

A value that represents either a success or a failure, including an associated value in each case.

Declaration

@frozen enum Result<Success, Failure> where Failure : Error

1	@frozen enum Result<Success, Failure> where Failure : Error

Before Result type below is the ways in which we create Asynchronous functions:

Objective – C style

func fetchData(url: URL, completionHandler: @escaping (Data?, Error?) -> Void) {
    ...
}

func fetchData(url: URL, completionHandler: @escaping (Data?, Error?) -> Void) {

...

}

The problem is that handling the result of the above function becomes quite tricky. Even if the error argument is nil, there’s no compile-time guarantee that the data we’re looking for is actually there — it might be nil as well for all we know, which would put our code in a bit of a strange state.

2. Swift Style

func fetchData(url: URL, successHandler: @escaping (Data) -> Void, errorHandler: @escaping (Error?) -> Void) {
    ...
}

func fetchData(url: URL, successHandler: @escaping (Data) -> Void, errorHandler: @escaping (Error?) -> Void) {

...

}

Result Type

They contain only 2 cases that both uses Swift Generic with associated value:

1. Success with the value of the result.

2. Failure with the type that implements Error protocol.

Implementation

The API which we are using for this is “https://jsonplaceholder.typicode.com/posts”. It is just a dummy API which sends back dummy results. The modal we have created for this demonstration is given below:

struct Post: Decodable {
    let title: String
    let body: String
}

enum NetworkError: Error {
    case domainError
    case decodingError
}

struct Post: Decodable {

let title: String

let body: String

}

enum NetworkError: Error {

case domainError

case decodingError

}

The Post model is marked with Decodable, which will help us to decode the response and populate our model. The NetworkError enum represents different cases for errors which we might encounter when during our networking adventures. Now that we have our models implemented let’s check out the implementation of fetchPosts function which is responsible for retrieving all the posts from the web API.

func fetchPosts(url: URL, completion: @escaping (Result<[Post],NetworkError>) -> Void) {
    
    URLSession.shared.dataTask(with: url) { data, response, error in
        
        guard let data = data, error == nil else {
            if let error = error as NSError?, error.domain == NSURLErrorDomain {
                    completion(.failure(.domainError))
            }
            return
        }
        
        do {
            let posts = try JSONDecoder().decode([Post].self, from: data)
            completion(.success(posts))
        } catch {
            completion(.failure(.decodingError))
        }
        
    }.resume()
    
}

func fetchPosts(url: URL, completion: @escaping (Result<[Post],NetworkError>) -> Void) {

URLSession.shared.dataTask(with: url) { data, response, error in

guard let data = data, error == nil else {

if let error = error as NSError?, error.domain == NSURLErrorDomain {

completion(.failure(.domainError))

}

return

}

do {

let posts = try JSONDecoder().decode([Post].self, from: data)

completion(.success(posts))

} catch {

completion(.failure(.decodingError))

}

}.resume()

}

Into The Standard Library

As part of Swift 5, the standard library is also getting its very own implementation of Result. One advantage of Result being included in the standard library is that individual frameworks and apps no longer have to define their own — and more importantly, no longer have to convert between different flavors of the same kind of type.

Swift 5 also brings another interesting change that’s heavily related to Result (in fact it was implemented as part of the same Swift evolution proposal) — and that’s that the Error protocol is now self-conforming. That means that Error can now be used as a generic type that is constrained to having to conform to that same protocol, meaning that the above NSError-based technique is no longer necessary in Swift 5 — as we can simply use the Error protocol itself to anonymize errors:

class ImageProcessor {
    typealias Handler = (Result<UIImage, Error>) -> Void

    func process(_ image: UIImage, then handler: @escaping Handler) {
        do {
            var image = try transformer.transform(image)
            image = try filter.apply(to: image)
            handler(.success(image))
        } catch {
            handler(.failure(error))
        }
    }
}

class ImageProcessor {

typealias Handler = (Result<UIImage, Error>) -> Void

func process(_ image: UIImage, then handler: @escaping Handler) {

do {

var image = try transformer.transform(image)

image = try filter.apply(to: image)

handler(.success(image))

} catch {

handler(.failure(error))

}

For More information about the Result Type you can check the official Swift Doc by visiting below mention link:

https://developer.apple.com/documentation/swift/result

siddhant kumar 25 June 2020

. . .

Result Type in Swift

According to Apple

Declaration

Objective – C style

2. Swift Style

Result Type

Implementation

Into The Standard Library

Leave a Comment Cancel Reply

Message Sent!