Typed errors

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 a more idiomatic code.
2. By using wrapper types, like Either, Option, or Result, we indicate that a computation might end with a logical error which we specify in the return type.

Regardless of your choice, Arrow provides a uniform API, and simple ways to move from one style to the other. You can find information about the different wrapper types in the corresponding section.

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, 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.

Validation

Worked out example of validation.

Wrapper types

Additional information about wrapper types: Either, Ior, Option, Result, nullable

From Either to Raise

Learning about Raise from other FP ecosystems.