Using Result type with async/await

[Jon_Shier]

I'm pretty sure it is, but you'll have to try and actually build it.

[Dmitriy_Ignatyev]

I have played some time in playground, the code now looks like:

func doSomething() {    
  fetchProducts()
    .mapSuccess { products in
      fetchProductImages(products)
    } onFailureDoFinally: { error in
      handleError(error: error)
    }
    .mapSuccess { productImages in
      processProductImages(productImages)
    } onFailureDoFinally: { error in
      handleError(error: error)
    }
}

extension Result {  
  @discardableResult
  func mapSuccess<NewSuccess, NewFailure>(onSuccess: (Success) -> Result<NewSuccess, NewFailure>,
                                          onFailureDoFinally: (Failure) -> Void) -> Result<NewSuccess, NewFailure>? {
    switch self {
    case let .success(value):
      return onSuccess(value)
    case let .failure(error):
      onFailureDoFinally(error)
      return nil
    }
  }
}

extension Optional {
  @discardableResult
  func mapSuccess<Success, Failure, NewSuccess, NewFailure>(onSuccess: (Success) -> Result<NewSuccess, NewFailure>,
                                                            onFailureDoFinally: (Failure) -> Void)
  -> Result<NewSuccess, NewFailure>? where Wrapped == Result<Success, Failure> {
    switch self {
    case let .success(value):
      return onSuccess(value)
    case let .failure(error):
      onFailureDoFinally(error)
      return nil
    case .none:
      return nil
    }
  }
}

So, technically it can be done, but I can hardly say it is as good API:

• it is easy to get a compiler error, the error explanation is hard to understand in long chains
• it can (and will, I suppose) be incorrectly used and understood
• control flow is weird

[Dmitriy_Ignatyev]

One more variant:

func doSomething() {    
  guard let products = fetchProducts().getValue(onErrorDo: { handleError(error: $0) }) else { return }
  
  guard let productImages = fetchProductImages(products).getValue(onErrorDo: { handleError(error: $0) }) else { return }
  
  guard let processedImages = processProductImages(productImages).getValue(onErrorDo: { handleError(error: $0) }) else { return }
}

extension Result {
  func getValue(onErrorDo: (Failure) -> Void) -> Success? {
    switch self {
    case .success(let success):
      return success
    case .failure(let error):
      onErrorDo(error)
      return nil
    }
  }
}

I've written synchronous variant for simplicity, async variant can also be done. May be it will help

[Peter-Schorn]

@Dmitriy_Ignatyev

func doSomething() {    
  fetchProducts()
    .mapSuccess { products in
      fetchProductImages(products)
    } onFailureDoFinally: { error in
      handleError(error: error)
    }
    .mapSuccess { productImages in
      processProductImages(productImages)
    } onFailureDoFinally: { error in
      handleError(error: error)
    }
}

This, adapted from my earlier example, seems simpler:

@Peter-Schorn

func doSomething() async -> [Order] {
    do {
        let products = try await fetchProducts().get()
        let customers = try await fetchCustomers(products: products).get()
        let orders = try await fetchOrders(customers: customers).get()
        return orders
    } catch {
        handleError(error)
        return []
    }
}

[Jeehut (Cihat Gündüz)]

I totally agree that there's something missing here and I suggested a solution to this problem here:

If/guard-let-catch for conveniently accessing both Result type cases

Motivation A few weeks ago, I had asked on Twitter if developers prefer error handling in Swift by using throws vs. returning Result. Of the 102 votes, 45% voted for "I prefer Result", which is 40% more than the 32% who voted for "I prefer throws" (source). While this small survey isn't representative by any means, it still proves that there's clearly high interest in using Result for error handling (and not only for closure return types), even if that means we have to build nested error types…

With my suggested change, you would be able to write:

guard let products = fechProducts() catch {
    handleFailure(error)
    return
}

Feel free to provide your usage example in the thread, too.