Swift Style

Choosing Result Types

Well-designed APIs report errors that allow the caller, its designated completion handler, or a delegate to support recovery and mitigation. Designing Result types supports this by integrating both success and error state into a single representation. You might consider passing optionals to your handlers, but Result types work better. Optionals express “there was no value.” Result types say “there’s no value and here’s why.”

The following snippet showcases some ways you could design a Result type:

public enum Result<T> {  // yes
    case success(T), error(Error)
}

public enum Result { // yes
    case success(URL, URLResponse)
    case error(Error)
}

Swift’s error-handling system struggles ...