Rich errors

[marco-eckstein]

In my understanding, the preferred way of domain error handling with Arrow is using the Raise DSL, while multiple alternative ways are also supported well. Now that Kotlin will soon have rich errors (in my understanding essentially an Either at the language level), what will be the future of error handling? Will rich errors be integrated into the Raise DSL like Either from the library? Should I start using Either everywhere in preparation for rich errors?

[nomisRev]

Hey @marco-eckstein,

That's a great question, but since the design of Rich Errors is not final yet it's not 100% clear what the results will be. It will depend on a couple of things:

• Will Rich Errors support short-circuiting, if yes then Rich Errors would effectively replace Either and we might (soft) deprecate Either with a long migration path. If we'd ever actually remove it remains to be seen depending on the needs of the community.

• If it doesn't support Rich Errors than most likely everyone will like to continue using Either or Raise in addition to Rich Errors. In that case we'd like to provide seamless interop where you could move back forth between Either, Raise or Rich Errors.

Arrow wants to provide the same guarantees as it currently has, but being idiomatic and feeling familiar in Kotlin is very important alongside binary compatibility being the most important factor.

[marco-eckstein]

Thanks!