The Result Type

enum MathError: Error {
    case divideByZero
}
func divide(_ a: Int, by b: Int) -> Result<Int, MathError> {
    if b == 0 {
        return .failure(.divideByZero)
    }
    return .success(a / b)
}
let result = divide(10, by: 2)
switch result {
case .success(let value):
    print("Result: \(value)")
case .failure(let error):
    print("Error: \(error)")
}

enum MathError: Error {
    case divideByZero
}
func divide(_ a: Int, by b: Int) -> Result<Int, MathError> {
    b == 0 ? .failure(.divideByZero) : .success(a / b)
}
do {
    let value = try divide(9, by: 0).get()
    print(value)
} catch {
    print("Caught via get(): \(error)")
}

1. Forgetting Result requires two generic types -- the success type and the failure (error) type -- both specified in its declaration.
2. Using switch on a Result but forgetting each case binds its own associated value (.success(let value) / .failure(let error)).
3. Choosing Result for a function's return type when a simple throws function would be simpler for synchronous code -- Result shines more for storing or passing outcomes around, especially in async callbacks.

• Result<Success, Failure> represents either .success(value) or .failure(error).
• It's especially useful for representing outcomes that need to be stored or passed around, not just handled immediately.
• switch is the natural way to handle both cases of a Result.
• Result requires its Failure type to conform to Error.