alexjpwalker
commented
2 years ago On closer inspection, Compose does not support the handling of errors in Composables. At all. See https://jetc.dev/slack/2020-10-26-compose-try-catch.html :
You cannot call a composable from within a try block of another composable. Calling from a catch block is OK, just not from try.
As various people on the thread pointed out, ideally, your composable is just declaring your UI. Anything with expected exceptions (disk I/O, network I/O, etc.) should be done outside of a composable anyway, such as in a viewmodel.
Google’s Jim Sproch explained that what seems like it might be simple… isn’t.
So, hopefully, in the future, this will be supported. In the meantime… just don’t write code that crashes, OK?
That means we have to ensure our application is bulletproof. This can only be achieved through rigorous adherence to encapsulation standards, and some integration tests would help too.
Problem to Solve
Compose gives us great flexibility to handle errors however we like. But if an exception is thrown and not handled by us, the application window will simply vanish. This is a pretty severe UX flaw.
Proposed Solution
We need some reusable methods to catch and handle application errors. And in the worst case where an error occurs in a composition that we don't handle, we should at least show some kind of prompt, and write the error to a log file.