Errores como datos

El contrato también cuenta cómo falla

Una búsqueda puede no encontrar un usuario. Una entrada puede ser inválida. Son resultados previstos del dominio, aunque no sean éxitos. Al incluirlos en el canal de error, el programa conserva esa información mientras lo transformás y combinás.

Una etiqueta identifica el caso sin depender de un mensaje para humanos. El mensaje puede cambiar; el contrato no debería depender de buscar una palabra dentro de un string.

import { Effect, Schema } from "effect"

class NoEncontrado extends Schema.TaggedError<NoEncontrado>()("NoEncontrado", {
  id: Schema.String
}) {}

const buscar = Effect.fail(new NoEncontrado({ id: "42" }))
const recuperar = buscar.pipe(
  Effect.catchTag("NoEncontrado", () => Effect.succeed("invitado"))
)

Recuperar es una decisión de producto

Devolver un invitado puede ser razonable para una vista pública y equivocado para una operación privada. catchTag expresa qué caso recuperás y con qué nuevo programa. No convierte cualquier fallo en un éxito ni decide por vos si el valor alternativo es correcto.

Conviene mantener separados los fallos previstos, los defectos inesperados y la interrupción. Una etiqueta de dominio no sustituye la observabilidad de un bug. Tampoco hay que ocultar una cancelación como si fuera un dato de negocio normal.

Leé el camino que realmente ocurrió

El lab compara success-path, fail-no-catch y fail-catch-tag. Primero predecí qué pasos se alcanzan. Después compará el error o el valor final y la traza registrada por el ejemplo.

Como ejercicio fuera del lab, elegí una operación de tu sistema. Enumerá dos fallos esperados y escribí qué debería hacer la interfaz con cada uno. Si ambos terminan en un mensaje genérico, revisá si el contrato está perdiendo información útil.