ursus
03/06/2019, 2:56 PMstreetsofboston
03/06/2019, 2:57 PMursus
03/06/2019, 2:57 PMstreetsofboston
03/06/2019, 2:57 PMEither
, the left/error value depends on your model, what errors are important. It highly depends on you domain modeltypealias FooError<T> = Either<FooErrorValues, T>
Al Warren
03/06/2019, 3:03 PMsealed 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
03/06/2019, 3:05 PMAl Warren
03/06/2019, 3:07 PMursus
03/06/2019, 3:09 PMfun 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
}
}
Al Warren
03/06/2019, 3:12 PMursus
03/06/2019, 3:14 PMAl Warren
03/06/2019, 3:21 PMfun fetchSomething(): Either<Failure, List<YourClass>>
. Somewhere along the way, you return Left(...)
which is a failure or Right(...)
which is a success.ursus
03/06/2019, 3:25 PMstreetsofboston
03/06/2019, 3:28 PMTry
from Arrowursus
03/06/2019, 3:31 PMstreetsofboston
03/06/2019, 3:33 PMdoFoo
, 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.ursus
03/06/2019, 3:35 PMstreetsofboston
03/06/2019, 4:55 PMursus
03/06/2019, 5:07 PM