https://kotlinlang.org logo
Join SlackCommunities
Powered by
do you have opionion on that?
# rx
u
do you have opionion on that?
z
yes. don’t use 
onError
for expected error scenarios. If you know sometimes can happen, it should go into onNext.
u
Okay so you explictly check for IOExeption etc? how do you do that in onErrorReturn ? it must return something
else throw
z
yes, I use onErrorReturn
Copy code
/**
 * Monad for an expected/unexpected result.
 */
sealed class Result<out T> {

    data class Expected<out T>(val result: T) : Result<T>()

    data class Unexpected(val exception: Exception) : Result<Nothing>()
}
u
yea but I think unexpected exceptions should crash
z
usually
not for network calls
u
why, networkcall = IOException expected
not if NPE in say your custom json parser, imho
đź‘Ť 1
how can you onErrorRturn only some, and crash on else?
onErrorResumeNext ( if throwable is expected Observable.just(ExpectedError) else Observable.error(throwable) ?
z
sure
u
btw, how can I know what is excepted, other than manually hunting? if everyting throws general Exception
and kotlin not having checked exceptions
and what your opinion on letting the app crash on unexpected exception
z
checked exceptions are ridiculous
use a sealed class + when
u
seales class for what
representing error state?
z
representing the possible return values of a function call
u
yes, but expected, not bugs. Would you let bugs crash or catch them all
z
bugs should crash
u
yea, same here. But how can I easily know what are the expected exceptions
z
but things like network calls can fail unexpectedly like with HTTP 500 responses. that’s a server side bug, not your app
I would display a generic error dialog for an http 500, but log it in analytics
u
yea, but you need a when + finite list of expected exceptions, how do you get it, only manully?
or should it be a responsibility of the caller to crash?
Open in Slack
PreviousNext
Powered by