https://kotlinlang.org
Join Slack
otherwise you might just stick with boolean
# announcements
u
otherwise you might just stick with boolean
s
Not sure what you mean…
u
okay ill write snippets
s
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
And a boolean for an error value may be good enough…
If need be, for readability, you can create a typealias over the Either. 
typealias FooError<T> = Either<FooErrorValues, T>
a
I do something like this with Either...
Copy code
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 -> ...
    }
}
u
well
is Failure general class or custom to a given call
a
It's something I do with API calls.
u
Copy code
fun doFoo() : Either<Foo, FooError> {
	
}

enum class FooError {
	BAR, QUAX, MEH
}
vs
Copy code
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'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
however, doing this for doFoo, doWhatever, etc. will cause types explosion so --- im not sure what poison to pick
a
u
okay, that a generic Either, my question is how do you model types of errors in a given either
lets say doFoo might return IO error, json parsing error, sqlite exception atd some other custom error
a
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.
u
I dont think you are getting what Im saying
s
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
u
@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
s
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.
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…
u
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> ?
s
It can be cleaner (using FooResult) when you never share any error-states between your functions.
u
Yea, deadend
6 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by