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

# arrow

[Zyle Moore]

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

[Zyle Moore]

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.

[Zyle Moore]

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?

[Zyle Moore]

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.

[Zyle Moore]

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?

[Patrick Louis]

Hey @Zyle Moore,

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.

[simon.vergauwen]

For testing, using getOrHandle always works.

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

[simon.vergauwen]

There is also some other integrations with other assertions libs

[simon.vergauwen]

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