otherwise you might just stick with boolean

Not sure what you mean…

okay ill write snippets

Based on the method/function that returns the

Either

, the left/error value depends on your model, what errors are important. It highly depends on you domain model

I do something like this with Either...

sealed class Failure {
    object NetworkConnection: Failure()
    object ServerError: Failure()
    object PermissionError: Failure()
    object NetworkOnMainThread: Failure()
}

private fun handleFailure(failure: Failure) {
    when(failure) {
        Failure.NetworkConnection -> ...
        Failure.ServerError -> ...
        Failure.PermissionError -> ...
        Failure.NetworkOnMainThread -> ...
    }
}

well

It's something I do with API calls.

fun doFoo() : Either<Foo, FooError> {
	
}

enum class FooError {
	BAR, QUAX, MEH
}

vs

fun doFoo() : FooResult {
	
}

sealed class FooResult {
	data class Success(foo : Foo) : FooResult()
	sealed class Error : FooResult {
		object Bar : Error
		object Quax : Error
		object Meh : Error
	}

}

This is what I use for Either... https://github.com/android10/Android-CleanArchitecture-Kotlin/blob/master/app/src/main/kotlin/com/fernandocejas/sample/core/functional/Either.kt

okay, that a generic Either, my question is how do you model types of errors in a given either

A method's return value would be Either... For example,

fun fetchSomething(): Either<Failure, List<YourClass>>

. Somewhere along the way, you return

Left(...)

which is a failure or

Right(...)

which is a success.

I dont think you are getting what Im saying

If you are not interested in the type of error, but just want to know whether an error happened or not, use the

Try

from Arrow

@streetsofboston I am interested, hence you need a custom enum, so, why not model the whole thing (including success) as a sealed class, so is the debate

Yep, then you need to model it. Like you suggested in your

doFoo

, that can return IO, parsing, sql etc error. Any difference in the type of error that is important to the calling code/function, you should generate a separate error-instance or error-type. Eg. IO error could be resolve by turning on WiFi by the client, but SQL error and DB error are hard errors. Then you’d model the IO exception in one sealed class value, the SQL and DB exception in another sealed class value.

yes, so, wouldnt a custom sealed FooResult be cleaner over Either<Foo, FooError> ? Even if you dont care about types of errors, how would you model that ..Either<Foo, Unit> ?

It can be cleaner (using FooResult) when you never share any error-states between your functions.

Yea, deadend