effect-error-handling

Use Schema.TaggedError to define error classes with a _tag discriminator and schema-validated fields. For module-internal errors without serialization needs, Data.TaggedError is a lighter alternative, and Schema.Error suits custom discriminator fields.

Effect.catchAll was renamed to Effect.catch in v4. Related renames include catchAllCause to catchCause, catchAllDefect to catchDefect, and catchSome to catchFilter, which uses the Filter module instead of Option.

In v4, catchTag accepts an array of tags to handle multiple error types with one handler, and catchTags takes an object mapping tags to handlers. Both support an optional trailing orElse parameter for unmatched errors.

Use defects via Effect.die for programming errors, invariant violations, and unrecoverable adapter-internal failures. Reserve the typed error channel for caller-actionable business failures that the next layer can recover from.

Effect v4 flattens Cause into an object with a reasons array containing Fail, Die, and Interrupt variants, replacing v3's recursive tree. Use Cause.findError, hasFails, and isFailReason instead of the old failureOption and isFailType APIs.

catchReason catches a specific reason variant nested inside a tagged error's reason field without removing the parent error. unwrapReason promotes the reason union into the error channel so individual reasons can be handled with catchTags.