Skip to main content
Mapagam

Working with Result Type

1. Understanding Result Type

Property Description Usage
Result<Success, Failure> Represents the outcome of an operation that can either succeed with a value or fail with an error Used as return type for asynchronous or potentially failing operations
success Associated value when operation succeeds Accessed via .get or pattern matching
failure Associated value when operation fails Accessed via .get or pattern matching

Example: Basic Result Usage

enum NetworkError: Error {
    case noConnection
    case timeout
}

func fetchData() -> Result<String, NetworkError> {
    // Simulate network call
    return .success("Data received")
}

let result = fetchData()
switch result {
case .success(let data):
    print("Received: \\(data)")
case .failure(let error):
    print("Error: \\(error)")
}
Note: Result is a generic type that encapsulates either a success value or a failure value, making error handling more explicit and safer than using optional types alone.

2. Creating Result Values

Method Description Example
Result.success(_) Creates a Result instance representing a successful operation. let successResult = Result<String, Error>.success("Operation completed")
Result.failure(_) Creates a Result instance representing a failed operation with an error. let failureResult = Result<String, Error>.failure(MyError.operationFailed)
Note: The Result type is generic and requires two type parameters: the success value type and the error type.

3. Unwrapping Result with Switch

Use a switch statement to handle the success or failure of a Result type.

Example: Unwrapping Result with Switch

let result: Result<String, Error> = .success("Hello, World!")

switch result {
case .success(let value):
    print("Success: " + value)
case .failure(let error):
    print("Error: " + error.localizedDescription)
}
Case Description Usage
.success(T) Represents a successful result with a value of type T. Use to handle the successful outcome.
.failure(Error) Represents a failed result with an error of type Error. Use to handle the failure outcome.
Note: The switch statement is the most idiomatic way to handle a Result in Swift.

4. Using get() Method

Method Description Return Type Notes
get() Retrieves the associated value of a Result instance if it's a success, or throws an error if it's a failure. Success Must be called on a Result<Success, Failure> instance where Failure conforms to Error.

Example: Using get() on a Result

enum NetworkError: Error {
    case noConnection
    case timeout
}

func fetchData() -> Result<String, NetworkError> {
    return .success("Data received")
}

let result = fetchData()
do {
    let data = try result.get()
    print(data) // Output: Data received
} catch {
    print("Error occurred: $error)")
}
Note: The get() method is a throwing function, so it must be called within a do block or with try.

5. Using map and flatMap on Result

Method Description Signature Example
map Transforms the success value of a Result if it's successful func map<U>(_ transform: (Success) throws -> U) rethrows -> Result<U, Failure> 
let result: Result<Int, Error> = .success(5)
let mapped = result.map { $0 * 2 } // Result<Int, Error>.success(10)
flatMap Transforms the success value of a Result and flattens nested Results func flatMap<U>(_ transform: (Success) throws -> Result<U, Failure>) rethrows -> Result<U, Failure> 
let result: Result<Int, Error> = .success(5)
let flatMapped = result.flatMap { value in
    return value > 0 ? .success(value * 2) : .failure(MyError.negativeValue)
} // Result<Int, Error>.success(10)
Note: map and flatMap only apply to the success case. If the Result is a failure, these methods return the failure unchanged.

6. Converting Throwing Functions to Result

Function Description Return Type Example
Result<T, E> Represents the outcome of an operation that may succeed or fail Result<SuccessType, ErrorType> let result: Result<String, Error> = .success("Hello")
Result<T, E>.success Initializes a Result with a success value Result<T, E> let successResult = Result<String, Error>.success("Success")
Result<T, E>.failure Initializes a Result with an error value Result<T, E> let failureResult = Result<String, Error>.failure(MyError())

Example: Converting Throwing Function to Result

func potentiallyFailingFunction() throws -> String {
    guard Bool.random() else {
        throw MyError()
    }
    return "Success"
}

func convertToResult(_ function: () throws -> String) -> Result<String, Error> {
    do {
        return .success(try function())
    } catch {
        return .failure(error)
    }
}

let result = convertToResult(potentiallyFailingFunction)

7. Using mapError for Error Transformation

The mapError method in Swift's Result type allows you to transform the error value of a Result without affecting its success value. This is particularly useful for converting between different error types or enriching error information.

Method Description Signature
mapError Transforms the error value of a Result into a new error type. func mapError<NewError>(_ transform: (Failure) -> NewError) -> Result<Success, NewError>

Example: Transforming Error Types

enum NetworkError: Error {
    case noConnection
    case timeout
}

enum APIError: Error {
    case invalidResponse
    case unauthorized
}

func fetchUserData() -> Result<String, NetworkError> {
    // Simulate a network call that might fail
    return .failure(.noConnection)
}

let result = fetchUserData().mapError { error in
    switch error {
    case .noConnection:
        return APIError.unauthorized
    case .timeout:
        return APIError.invalidResponse
    }
}

// The result now has type Result<String, APIError>

Example: Adding Context to Errors

enum DataError: Error {
    case invalidFormat
    case missingField(String)
}

struct User {
    let name: String
    let email: String
}

func parseUser(from data: String) -> Result<User, DataError> {
    // Simulate parsing logic
    return .failure(.invalidFormat)
}

let rawResult = parseUser(from: "some data")

let enrichedResult = rawResult.mapError { error in
    switch error {
    case .invalidFormat:
        return DataError.missingField("name")
    case let .missingField(fieldName):
        return DataError.missingField(fieldName)
    }
}

// The enrichedResult now includes more context about the missing field

8. Combining Result with async/await

Feature Description Example
Result<T, Error> Represents either a successful value or an error 
enum NetworkError: Error {
    case noConnection
    case timeout
}

typealias ApiResponse = Result<String, NetworkError>
async/await with Result Use Result in async functions to handle success or failure 
func fetchUserData() async -> Result<User, NetworkError> {
    do {
        let data = try await fetchDataFromAPI()
        return .success(User(from: data))
    } catch {
        return .failure(.noConnection)
    }
}

Example: Using Result with async/await

func fetchAndProcessData() async {
    let result = await fetchUserData()
    
    switch result {
    case .success(let user):
        print("User: \\(user.name)")
    case .failure(let error):
        print("Error: \\(error)")
    }
}
Note: When using Result with async functions, the function must be declared as async and return a Result type.
Warning: Be cautious when mixing Result and async/await in complex workflows. Ensure proper error propagation to avoid silent failures.

9. Implementing Custom Result Extensions

Extension Description Usage
flatMap Transforms a Result into another Result, flattening nested Results 
extension Result<T, E> {
    func flatMap<U>(transform: (T) -> Result<U, E>) -> Result<U, E> {
        switch self {
        case .success(let value):
            return transform(value)
        case .failure(let error):
            return .failure(error)
        }
    }
}
map Transforms the success value of a Result if it exists 
extension Result<T, E> {
    func map<U>(transform: (T) -> U) -> Result<U, E> {
        switch self {
        case .success(let value):
            return .success(transform(value))
        case .failure(let error):
            return .failure(error)
        }
    }
}
get Retrieves the value or throws an error if it's a failure 
extension Result<T, E> {
    func get() throws -> T {
        switch self {
        case .success(let value):
            return value
        case .failure(let error):
            throw error
        }
    }
}

Example: Using flatMap to Chain Operations

func fetchUser(id: String) -> Result<User, Error> {
    // Simulate fetching user
    return .success(User(id: id, name: "John"))
}

func fetchPosts(for user: User) -> Result<[Post], Error> {
    // Simulate fetching posts
    return .success([Post(title: "First Post")])
}

let result = fetchUser(id: "123")
    .flatMap { fetchPosts(for: $0) }
    .map { posts in posts.map { $0.title } }

print(result) // Success: ["First Post"]

Example: Safe Error Handling with get()

let result: Result<String, Error> = .success("Hello")

do {
    let value = try result.get()
    print(value) // "Hello"
} catch {
    print("Error: \(error)")
}

10. Handling Network Responses with Result

Property Description Usage
Result<Success, Failure> Represents the outcome of an operation that can either succeed or fail Result<String, Error>
success Value returned when operation succeeds Result.success("Data received")
failure Error object returned when operation fails Result.failure(NetworkError.noConnection)

Example: Using Result in Network Call

enum NetworkError: Error {
    case noConnection
    case timeout
}

func fetchUserData(completion: (Result<String, NetworkError>) -> Void) {
    // Simulate network call
    if true {
        completion(.success("User data: John Doe"))
    } else {
        completion(.failure(.noConnection))
    }
}

fetchUserData { result in
    switch result {
    case .success(let data):
        print("Received: \\(data)")
    case .failure(let error):
        print("Error: \\(error)")
    }
}
Note: Using Result helps avoid force unwrapping and makes error handling more explicit.

Best Practices for Result Usage

  • Use Result in asynchronous operations to handle success and failure cases explicitly
  • Define custom error types that conform to Error protocol
  • Avoid using try! or force unwrapping when working with Result

Was this article helpful?

Related Cheat Sheets