https://kotlinlang.org logo
#compose
Title
# compose
z

Zach Klippenstein (he/him) [MOD]

04/15/2020, 8:28 PM
Was handling Rx errors by re-throwing them from the composition point considered? I think it’s more dangerous to drop exceptions automatically then thrown them – I’ve been bitten quite often by forgetting to wire up the Rx error handling behavior and dropping exceptions because of that. It would seem intuitive to me for
subscribeAsState
to behave like `Flow`’s
collect
. If you wrapped the exception outside the
remember
block before rethrowing, the stack traces would probably be really helpful for debugging as well. Errors still “should” be handled by
onErrorReturn
and friends, but at least that would reduce the likelihood that actual exceptions get dropped on the floor by accident.
a

Andrey Kulikov

04/15/2020, 8:56 PM
they are not dropped currently. it will crash with a regular OnErrorNotImplemented exception so we don't swallow it. and yes, we expect people to use
onErrorReturn
when you do expect that it can give you an error
a

Adam Powell

04/15/2020, 11:28 PM
additionally, the behavior of try/catch around a composable function call is not well-defined right now. Thanks to the way we can restart deeper calls in a composable call hierarchy, the try/catch might not be part of the call stack.
it's not quite like suspend where there's a sort of "logical" point in the call stack we can resume from, we would have to do something weird like recompose the caller just to throw an exception if the offending function is called again, and there's no real guarantee it would be.
👍 1
3 Views