About Technique for Treating Error as an NSError (Equatable)

[asapo]

In the examples in the TCA repository, I sometimes see examples of casting Error to NSError for comparison.
However, can we trust this method?
This is because different values may be treated as the same, as shown below.

$ swift                           
Welcome to Apple Swift version 5.4.2 (swiftlang-1205.0.28.2 clang-1205.0.19.57).
Type :help for assistance.
  1> import Foundation
  2> struct MyError: LocalizedError { let errorDescription: String? } 
  3> MyError(errorDescription: "a") as NSError == MyError(errorDescription: "a") as NSError
$R0: Bool = true // ok!
  4> MyError(errorDescription: "a") as NSError == MyError(errorDescription: "b") as NSError 
$R1: Bool = true // 🥺

When you want to have an Error in an Action, you mainly want to make it conform to Equatable at test time!
In this case, I thought it would be better to initialize the NSError directly, instead of the error defined in Swift.
Like this:

swift-composable-architecture/Tests/ComposableArchitectureTests/EffectTests.swift

Line 190 in 96cdc7e

Effect<Never, Error>(error: NSError(domain: "", code: 1))

let error = NSError(code: 0, domain: "com.example")
let client = SomeClient(fetch: { Effect(error: error) })

enum Action: Equatable {
    case response(Result<Int, NSError>)
}

// testing
store.receive(.response(.failure(error))) { // ok
    $0.error = error // ok
}

If you want to have Error in State, you want to make it conform to Equatable when using WithViewStore or when testing.
This may not be a problem when testing (In this case, we can initialize NSError directly), but in a production implementation, the Error defined in Swift may be cast to an NSError and
As shown above, it may not be the same, but it may be determined to be the same.
If this happens, the View may not be redrawn.

struct State: Equatable {
    var error: NSError? // for example, MyError above 
}
//   4> MyError(errorDescription: "a") as NSError == MyError(errorDescription: "b") as NSError 
// $R1: Bool = true // 🥺

In such a case, a possible approach is to not have Error in the State, and only keep the necessary data.

struct State: Equatable {
    var errorMessage: String?
}

Another way is to wrap the Error.

final class ErrorWrapper: Equatable {
    let underlyingError: Error

    func == (lhs: ErrorWrapper, rhs: ErrorWrapper) {
        lhs === rhs // same reference
    }
}

// or

struct ErrorWrapper: Equatable {
    let underlyingError: Error
    let id: UUID = .init()

    func == (lhs: ErrorWrapper, rhs: ErrorWrapper) {
        lhs.id == rhs.id
    }
}

However, this is not available in the Result, so the Wrapper will also want to conform to Error.

struct ErrorWrapper: Equatable, Error {}

enum Action {
    case response(Result<Int, ErrorWrapper>) // ok
}

However, since the ErrorWrapper is not an actual error, you need to handle it by taking out the underlyingError.
You'll need to be careful if you want to present a message, for example.

let error: ErrorWrapper = //
state.alert = error.localizedDescription // wrong
state.alert = error.underlyingError.localizedDescription // ok

As you can see, there are various considerations regarding Error and Equatable.

I'm sure each app is different in how it should be handled, but if someone have any recommendations or ideas, please let me know.

[AlexisQapa]

I'm also interested in the question, lately I've been conforming Action to Equatable only in test modules like.
The biggest pain point I've found is using TCA provided States for Alerts which require Action to be Equatable to be Equatable.

extension Action: Equatable {
	public static func == (lhs: Action, rhs: Action) -> Bool {
		String(reflecting: lhs) == String(reflecting: rhs)
	}
}

[asapo]

Thanks for the idea! The way of conforming to Equatable only in tests may be useful in some cases👍

[stephencelis]

Thanks for the question! It's a good one! We consider our as NSError casting as a "quick fix" mainly, that can help unblock you while you first sketch out a feature and write tests for it, but would not recommend it for complex error handling. It's really only good for handling the most basic failure case, which is that an error happened at all.

As soon as you care about the error information, we would not recommend using as NSError, and instead recommend introducing your own error types that are more aware of how things can fail. We do this in the Tic-Tac-Toe demo:

swift-composable-architecture/Examples/TicTacToe/tic-tac-toe/Sources/AuthenticationClient/AuthenticationClient.swift

Lines 43 to 58 in 18340e6

	public enum AuthenticationError: Equatable, LocalizedError {
	case invalidUserPassword
	case invalidTwoFactor
	case invalidIntermediateToken
	public var errorDescription: String? {
	switch self {
	case .invalidUserPassword:
	return "Unknown user or invalid password."
	case .invalidTwoFactor:
	return "Invalid second factor (try 1234)"
	case .invalidIntermediateToken:
	return "404!! What happened to your token there bud?!?!"
	}
	}
	}

We recommend introducing domain-specific error types such as these whenever you want to start handling errors in a nuanced way. You may still need to be careful when handling errors that come from outside your domain in order to translate them into the correct errors in your domain.

[asapo]

Thank you for your opinion about NSError.
Domain-specific error types were certainly a good way to go👍

However, since there are errors coming from an API server or undocumented information coming from within the SDK etc, I think it is difficult to define everything properly.

And if we define it as unknown, we may lose the original information, so it's difficult to find a balance between making it Equitable while keeping the information necessary for debugging.

In some cases, it may be better to simply wrap it. For example:
https://github.com/pointfreeco/composable-core-location/blob/daf7032ada2c8088e0e69e7e7d4dacfeb604bf7c/Sources/ComposableCoreLocation/Interface.swift#L241-L247

Just wanted to thank you for your response on the basic policy 😀.
I think what should be done depends on the application, and the way to do it varies, but I will think about it further.

[asapo]

@stephencelis
As far as testing is concerned, how about having a version of the receive method that does not require the Action's Equatable constraint?

Original:

swift-composable-architecture/Sources/ComposableArchitecture/TestSupport/TestStore.swift

Lines 393 to 399 in 575d7c0

	extension TestStore where LocalState: Equatable, Action: Equatable {
	public func receive(
	_ expectedAction: Action,
	file: StaticString = #file,
	line: UInt = #line,
	_ update: @escaping (inout LocalState) throws -> Void = { _ in }
	) {

For example, take a closure as an argument:

extension TestStore where LocalState: Equatable {
  public func receive(
    _ expectedAction: (Action) -> Bool,
    file: StaticString = #file,
    line: UInt = #line,
    _ update: @escaping (inout LocalState) throws -> Void = { _ in }
  ) {

testStore.receive({ CustomDump.diff($0, Action.someError(myError)) == nil })

As AlexisQapa says, it may not make much difference to conform to Equatable only in testing 🤔

[asapo]

🤔

struct MyClient {
    var fetch: () -> Effect<Int, Error>
}

enum Action {
    case error(Error)
}

// testing

struct TestError: Error, Equatable {
   let id = UUID()
}

let error = TestError()
client.fetch = { Effect(error: error) }

testStore.receive(
    { action in
        if case let .error(e as TestError) = action, e == error {
            return true
        } else {
            return false
        }
    }
)