What's the plan regarding try/catch with compose? I really want my parent components to be able to catch and handle certain exceptions from children

Resuming such that try/catch behaves in the usual imperative expected way may or may not be particularly practical, especially because error display and recovery with exception handling is kind of imperative/stateful to begin with

Often you want to download something from you server and than show the result or an error message maybe also show some kind of loading progress. For this i use following code snipped. The result of loadingStateFor can be used in your child component to show progress. In general you would use a when() statement to decide what UI element to show.

sealed class LoadingState<out T: Any> {
    object Start: LoadingState<Nothing>()
    object Loading : LoadingState<Nothing>()
    class Error(val error: Throwable): LoadingState<Nothing>()
    class Success<T: Any>(val data: T): LoadingState<T>()
}
@Composable
fun <T: Any> loadingStateFor(vararg inputs: Any?, initBlock: () -> LoadingState<T>, disposeBlock: () -> Unit = {}, loadingBlock: suspend CoroutineScope.() -> T): LoadingState<T> {
    var state by stateFor(*inputs, init = initBlock)

    onCommit(*inputs) {
        val job = if (state !is LoadingState.Success) {
            CoroutineScope(Dispatchers.Main.immediate).launch {
                val loadingSpinnerDelay = async {
                    delay(500)
                    state = LoadingState.Loading
                }
                state = try {
                    LoadingState.Success(loadingBlock())
                } catch (err: Throwable) {
                    LoadingState.Error(err)
                } finally {
                    loadingSpinnerDelay.cancelAndJoin()
                }
            }
        } else null
        onDispose {
            job?.cancel()
            disposeBlock()
        }
    }
    return state
}

That all makes sense Adam, I hadn’t really thought it through completely! I’ll explain what I was thinking about writing anyway. Any network request in my app may return with an error that should result in the user getting logged out. Rather than make every service have this potential error as a part of its result API, I thought it would be nice if this just became an exception I could throw. Then one of my top-level composables could catch that error and adjust its state such that the app would start logging out, e.g:

@Composable
fun App() {
  val (state, setState) = ...
  when (state) {
    LOGGED_OUT -> { 
      LoginFlow(...)
    }
    LOGGING_OUT -> {
      LoggingOut(onComplete = {
        setState(LOGGED_OUT)
      })
    }
    LOGGED_IN -> {
      try {
        UserFlow(...)
      } catch (ex: MyException) {
        setState(LOGGING_OUT)
      }
    }
  }
}

Yes, exactly - you need some extra machinery around that resulting state transition to make sure you don't just end up in a recomposition loop, plus if it's an internal restart of some implementation detail inside

UserFlow

that triggers the exception, how and what do we restart about the callers when those callers don't have a stack frame anywhere? They completed running long ago. Control flow isn't in the try block anymore.

Yeah I have no idea how that would work! Thanks for the explanation

I think you should use some kind of business logic layer in your app. And do not do such things on the UI layer. This businesslayer component could than expose the state to the UI using e.g. @Model classes.