A modern programming language that makes developers happier.

kotlinlang

Hello, I have a question about Either type resolution/conventions when it comes to errors, and Sum Types.

The first part of my question is about error types. In the examples I saw on the Arrow Core Either docs, it mentions making a sealed hierarchy for expected exception types. `NotANumber : Error()` and `NoZeroReciprocal : Error()` for example. Or from the Error Handling Tutorial, it has the parent type as a `CookingException`, despite it not being a subtype of Throwable or Exception.

The first question is: should these Error Sum Types subtype Exception or Throwable? If they don't subtype one of these, should we call them Errors instead of Exceptions?

I feel like this might be in the realm of personal choice, but was just looking for guidance on conventions if there were some that I missed.

The second question is about getting the value of an Either during a Unit Test. In this context, I need to get the value of an Either.Right. If it's an Either.Left, then I just `fail` the Test.
It looks something like
```val kokiriForestDoor = Name("Kokiri Forest")
    .map { Door(it) }
    .getOrHandle { fail { "$it" } }```
Is this (about) the right way to handle something like this?

Hey <@U02DT8VPX6C>,
&gt; The first question is: should these Error Sum Types subtype Exception or Throwable? If they don't subtype one of these, should we call them Errors instead of Exceptions?
IMHO they should be completely separate from the `Exception`/`Throwable` hierarchy. If you need to capture a `Throwable` in one you can always create an alternate constructor for your sum type like
```sealed class YourError {
  data class SomeException(val e: Throwable) : YourError()
...
}```
On the second part of your question I do also think that it is good to call the sum type something with Error, we usually call the top-most type `DomainError` because it represents any error that might occur in the domain of the application.
You can however still give a name like SomeException single constructors if they are intended to hold an exception, like in my above example.

For testing, using getOrHandle always works.

But maybe more convenient is <https://github.com/kotest/kotest-extensions-arrow|https://github.com/kotest/kotest-extensions-arrow> 

There is also some other integrations with other assertions libs 

Ofc you can also just do assertEquals(actual, Either.Right(expected))