Typed errors refer to a technique from functional programming in which we make explicit in the signature (or type) the potential errors that may arise during the execution of a piece of code. Arrow provides two different approaches to typed errors:

1. The Raise DSL uses an extension receiver which represents a context in which errors of a certain type may be raised. This approach often results in more idiomatic code.
2. Using wrapper types, like Either, Option, or Result, we indicate that a computation may end with a logical error by decorating the return type.

Regardless of your choice, Arrow provides a uniform API, and simple ways to move from one style to the other.

If you want a general introduction we recommend the tutorial about working with typed errors, followed by how to model validation in this style.

If you are already familiar with Either and similar wrapper types, you can find information about their Arrow counterparts (Nullable and Option, Either and Ior). We stongly recommend to read From Either to Raise to understand how you can benefit from the typed errors DSL.

Where to find it

Typed errors live in the arrow-core library, with high-arity versions of the zipOrAccumulate function available in arrow-core-high-arity.

Working with typed errors

Working, recovering, and accumulating errors in a typed and concise way.

Why nullable types & Option?

Difference between nullable types and Option, and when to use each.

Either & Ior

Use cases for Either and Ior.

Validation

Worked out example of validation.

From Either to Raise

Learning about Raise from other FP ecosystems.

Creating your own error wrappers

Writing your own DSLs with Raise.