Typed errors

[nomisRev]

This PR adds a draft document for the typed error tutorial. I am not entirely happy with the domain, etc... but I think it covers all the important topics we need to cover in this document.

Sadly with Kotlin 2.0 announced we now that context receivers are still quite some time away, so I didn't mention them on this tutorial which I think should be the backbone of Arrow Core. So be sure to be critical about the domain, examples, and content! And anything missing ☺️

Some missing topics, but we probably better to create separate issues for them and collaborate further on this document. Let's brainstorm a list of topics here before turning them into tickets.

• zipOrAccumulate
• Ior
• Option vs nullable

[nomisRev]

@franciscodr can we invite Jose, and the Kotlin team to review and comment on these PRs as well?

[franciscodr]

@franciscodr can we invite Jose, and the Kotlin team to review and comment on these PRs as well?

@nomisRev I have just added the whole Kotlin team, including Jose Gutierrez and Qohat

[nomisRev]

Great suggestions, thank you @pakoito 🙌

[raulraja]

I love the article, and it's perfect for showing how to use the API. I think using names like DatabaseError, NetworkError etc., would also be suitable for all the examples and perhaps more engaging than the current generic examples like MyError.
The architectural layer concerns errors that can be used from top to bottom, showing people how to recover and translate errors from one side to the other are close to the problems users face in their real-world projects. We could have a hierarchy like:

ViewError
ModelError
PersistenceError

Or a similar structure that shows how they are handled and translated through layers until the edge over a use case such as login or similar, which requires validation and handling potential failures.

[gutiory]

LGTM!.
I just left some minor comments. Feel free to use them or not 😄 .

[nomisRev]

I'm going to merge this PR, we can improve the domain errors @raulraja but I couldn't find a convenient way to update it in this PR easily without making it a lot longer and involving other concerns.

In the Kotlin meeting @franciscodr, @serras and myself discussed adding a page about structuring code. This can perhaps go in the "use-case" section, or another tutorial page explaining layering of applications with typed errors.

I think this document serves as the documentation around Raise, so perhaps Typed Errors is not the right name for this document. We could also rename it Working with Raise.

Feel free to add more comments to this PR after it's closed, and we can turn them into issues/action items.