Fail-fast when trying to do `runBlocking` from Android UI thread

Android UI thread does not generally allow blocking operations and vaiours things like doing network IO from UI thread throws an exception on Android. Similarly, using runBlocking from Android UI thread shall throw an exception to fail-fast and prevent hard-to-diagnose bugs when the code just “happens to run fast” during testing but can in fact hang the UI in production.

[svenjacobs]

I have a bit of coroutine code that needs to be run in a blocking fashion when my Android application starts. For instance in my Application class I need to fetch a value from a suspending function. Based on the result of that value certain application options are configured. This should actually block because the configuration needs to be finished before/while the application starts. This worked well before version 0.24 and was not noticeable.

How do I solve this use case now?

[jcornaz]

I have to say I like the Idea. But why only forbid runBlocking on UI threads? Blocking a thread of the fork-join-pool is also bad practice.

And actually, even if I like very much the Idea I have some fears about our usage. In our codebase we are slowly adding coroutines and improving our code base to block as less often as possible. But we have to live with an existing code base which has legacy code blocking the UI (without using coroutine). And problems arise when we convert some code or add new code using coroutines. Even if we try as much as possible to make the code not blocking the UI anymore, it is sometime to much work and we simply put the suspending code in runBlocking and create a refactoring issue for later. After all, the code under modification was already blocking the UI, and we cannot completely rewrite the application each time we add a small feature. And at the end, it is still nice to use runBlocking, because it makes it obvious that the code is blocking and that further refactoring is needed.

But if kotlinx.coroutines sudently start to throw exceptions when we use runBlocking in UI thread what should we do? Our code base is too massive to make it completely non-ui-blocking in a reasonable amount of time.