Was handling Rx errors by re-throwing them from th...

# compose

[Zach Klippenstein (he/him) [MOD]]

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.

[Andrey Kulikov]

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

[Adam Powell]

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.

[Adam Powell]

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.