otherwise you might just stick with boolean

# announcements

[ursus]

otherwise you might just stick with boolean

[streetsofboston]

Not sure what you mean…

[ursus]

okay ill write snippets

[streetsofboston]

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

[streetsofboston]

And a boolean for an error value may be good enough…

[streetsofboston]

If need be, for readability, you can create a typealias over the Either. typealias FooError<T> = Either<FooErrorValues, T>

[Al Warren]

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 -> ...
    }
}

[ursus]

well

[ursus]

is Failure general class or custom to a given call

[Al Warren]

It's something I do with API calls.

[ursus]

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
	}

}

[ursus]

this is what I'm talking about, that the generic Either is supposed to be less code, etc, but you most likely will end up using some kind of enum to communicate types of errors, so why not model is as a custom hierarchy all together

[ursus]

however, doing this for doFoo, doWhatever, etc. will cause types explosion so --- im not sure what poison to pick

[Al Warren]

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

[ursus]

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

[ursus]

lets say doFoo might return IO error, json parsing error, sqlite exception atd some other custom error

[Al Warren]

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.

[ursus]

I dont think you are getting what Im saying

[streetsofboston]

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

[ursus]

@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

[streetsofboston]

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.

[streetsofboston]

Modeling errors is tricky. You’d have to think about what the caller can do with them, whether returning a different error value would make the caller do different things or not…

[ursus]

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> ?

[streetsofboston]

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

[ursus]

Yea, deadend