Storing Errors in State

[rzulkoski]

I have a use case where it would be useful to store an Error as part of state. The issue is that errors aren't inherently Equatable, so I'm trying to weigh my options. The first idea that comes to mind is creating a box that holds onto the original error and conforms to equatable.

Some details around the use case:

1. I have a shared component view that wraps a List and sets the background based on different conditions.
2. When the list is empty and there is an error, it will show different backgrounds depending on the error. (e.g. offline verbiage when internal offline error thrown, server message when internal API error with message thrown, default generic error message otherwise)

Has anyone else come up against this problem? If so, what was your solve and are you happy with it? Is this strategy of holding onto the error and having the view inspect it an anti-pattern?

[jshier]

I'll let Brandon and Stephen weigh in on their solution (TaskResult with introspective equality) but I've found this a major pain point as well. I tried TaskResult but found that the vast majority of Apple's Error types aren't actually Equatable at all (especially in the framework I was consuming), so it ended up not being viable. Instead, I now generate my own Equatable in my wrapping Error types through a variety of means, including direct NSError equality, localizedDescription or errorDescription equality, or equality of various properties of concrete error types. I can get particular test cases to pass but I these aren't really general solutions. I'm not sure where to go from here.

[tgrapperon]

Hey @rzulkoski! While it is maybe possible to hack TaskResult Error amenities, I would recommend to define your own "UserFacingError" plain old data type from which you would create values to store into the state when an Error is received. For example, something like:

struct UserFacingError: Equatable {
  let title: String
  let description: String
  let color: Color
}

I wouldn't use Errors to directly model things on the UI's side.

[jshier]

This is a good suggestion. My use of Error values comes from my actions, not my state, usually, so having a proper state representation can alleviate some of the pain on that side of the issue.

[rzulkoski]

Yeah that's fair. I will explore what that might look like in the project I'm working on and report back here with my findings.

[rzulkoski]

Circling back here to say that we ended up defining something with this shape:

enum ErrorState: Equatable, Error {
  case generic
  case internetRequired
  case verbose(message: String)

  init(error: Error) {
    // Checking for specific errors
    if ... {
      // * snip
    } else {
      self = .generic
    }
  }
}

Then from our reducer we can add any logic we want to handle a specific error and then if we need to hold onto it we can create the appropriate ErrorState and gain the equality that we were missing before. This also made it more straight-forward to handle the different UI bits in our shared view components as we could directly switch over the enumerated cases we might want to show to the user rather than having to classify the error itself at that point.