Manejar el fallo: convertir errores en acciones de respuesta

En una arquitectura de flujo unidireccional, un error no es una excepción que sube por la pila hasta que alguien la atrapa: es un hecho del dominio, y como todo hecho del dominio tiene que llegar al reducer convertido en acción. El efecto es el único sitio donde puede fallar algo —porque es el único sitio donde ocurre algo—, así que también es el sitio donde el fallo debe traducirse. Un throws que se escapa de un efecto sin traducir es una pieza de información que tu aplicación ha perdido: nadie mutó el estado, nadie mostró nada, y el usuario se queda mirando un spinner eterno. Manejar el fallo en TCA es, sobre todo, un ejercicio de nomenclatura.

El manejador de fallo del efecto

El constructor .run admite un segundo parámetro, catch:, que recibe el error y el mismo send de la operación. Su trabajo es uno solo: traducir el error a una acción del dominio para que el reducer decida qué hacer con él.

case .actualizarPulsado:
  state.cargando = true
  return .run { send in
    let articulos = try await cliente.cargarArticulos()
    await send(.datosRecibidos(articulos))
  } catch: { error, send in
    await send(.falloDeCarga(error.localizedDescription))
  }

Hay un detalle de diseño que conviene conocer al dedillo: la cancelación no es un fallo. Cuando el store cancela un efecto, la tarea lanza un CancellationError, y el constructor lo descarta en silencio sin llamar a tu manejador. Es lo correcto: que el usuario cambie de pantalla y una petición se aborte no es un error que mostrar, es el funcionamiento normal del ciclo de vida. Si el manejador se disparara ahí, cada navegación pintaría una alerta de fallo fantasma.

Result en la acción: un caso para dos desenlaces

El manejador catch: es una red de seguridad de última instancia, y tiene una limitación estructural: cubre la closure entera, así que no sabe cuál de los tres await falló. Cuando cada fallo merece una respuesta distinta, la captura se hace dentro, junto al await que puede fallar, y el resultado viaja en un único caso de acción que lleva el desenlace completo.

enum Action {
  case actualizarPulsado
  case respuesta(Result<[Articulo], FalloDeCarga>)
}

case .actualizarPulsado:
  state.cargando = true
  return .run { send in
    do {
      await send(.respuesta(.success(try await cliente.cargarArticulos())))
    } catch let fallo as FalloDeCarga {
      await send(.respuesta(.failure(fallo)))
    }
  }

Un solo caso de acción para los dos desenlaces tiene una consecuencia muy práctica en el reducer: el switch obliga a escribir las dos ramas juntas, y ahí es donde se apaga el indicador de carga una sola vez, se guardan los datos o se guarda el mensaje. Con dos casos separados —uno de éxito y otro de fallo— la lógica común se duplica y tarde o temprano una de las copias se olvida de apagar el spinner.

case let .respuesta(resultado):
  state.cargando = false
  switch resultado {
  case let .success(articulos):
    state.articulos = articulos
    state.fallo = nil
  case let .failure(fallo):
    state.fallo = fallo
  }
  return .none

La primera línea es la que justifica el diseño: state.cargando = false se escribe una vez y cubre los dos desenlaces, porque los dos desenlaces son el mismo hecho —la respuesta llegó— con contenido distinto. Modelar el resultado como una suma en lugar de como dos hechos independientes es lo que permite factorizar esa parte común sin acordarse de ella.

Nombrar el fallo: el error como parte del dominio

Propagar any Error desde la red hasta la vista es la forma más rápida de acabar mostrando cadenas incomprensibles al usuario. El fallo se modela igual que cualquier otro dato del dominio: con un enum cerrado, Equatable, traducido en la frontera de la dependencia, donde todavía se sabe lo que significó cada código.

enum FalloDeCarga: Error, Equatable {
  case sinConexion
  case noAutorizado
  case servidor(codigo: Int)
  case respuestaIlegible
}

func cargarArticulos() async throws(FalloDeCarga) -> [Articulo]

Con los lanzamientos tipados de Swift 6 la firma declara exactamente qué puede fallar, y el compilador se vuelve tu revisor: al hacer switch sobre el Result en el reducer tendrás que decidir qué pasa en cada caso, y añadir mañana un .mantenimiento romperá la compilación en todos los sitios donde había que decidir. Eso es precisamente lo que quieres de un error importante.

flowchart LR
W[Mundo exterior] -->|error crudo| D[Dependencia traduce]
D -->|FalloDeCarga| E[Efecto run]
E -->|accion respuesta| R[Reducer decide]
R --> S[State con mensaje o reintento]
style D fill:#f9e2af,color:#11111b
style R fill:#cba6f7,color:#11111b

No todo fallo merece el mismo tratamiento, y esa es una decisión de producto que el reducer debe expresar caso por caso. Cuando el error es un enum del dominio, esas políticas son ramas legibles de un switch; cuando es any Error, son comparaciones de cadenas esperando a romperse.

El tercer caso ilustra bien que la política vive dentro del efecto cuando es puramente mecánica: reintentar con espera creciente es un bucle dentro de la closure, sin pasar por el reducer en cada intento.

return .run { send in
  for intento in 0..<3 {
    do {
      await send(.respuesta(.success(try await cliente.cargarArticulos())))
      return
    } catch is FalloDeCarga {
      try await clock.sleep(for: .seconds(pow(2.0, Double(intento))))
    }
  }
  await send(.respuesta(.failure(.servidor(codigo: 503))))
}

Que el reloj sea una dependencia inyectada es lo que impide que este efecto vuelva tu suite de tests lenta: con un reloj de prueba, los siete segundos de espera se saltan avanzando el tiempo a mano, y el test sigue comprobando exactamente la misma lógica de reintento.