Maybe a dumb question (EDIT: certainly dumb question :upside_down_face:) but how can I force app cra...

# coroutines

[Filip Wiesner]

Maybe a dumb question (EDIT: certainly dumb question 🙃) but how can I force app crash (Android) when child of SupervisorJob (viewModelScope) throws exception?
My use case is that when debugging I want my app to crash whenever there is unhandled exception anywhere in my business logic but because viewModelScope is SupervisorJob, the coroutine is only getting cancelled.
This behavior can be achieved by using Dispatchers.Main as context (presumably because it calls android UncaughtExceptionHandler) but I how can I achieve this when using .Default or .IO dispatchers?

[Filip Wiesner]

I tried adding my own CoroutineExceptionHandler and re-throwing the exception but without luck.

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

You can kill the app by calling System.exit from your handler

[Filip Wiesner]

Sigh...sometimes things are too obvious to think of. Thanks Zach, you saved my day 🤦‍♂️

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

It’s easy to forget, you don’t see System much in Android 😅

[louiscad]

I think the app should crash automatically if you're using launch (but not async which should be part of a child non supervisor scope.

[uli]

I think, even async will crash. But only when you await, which will rethrow.

[Filip Wiesner]

I thought so too but it doesn't crash and I don't know what I'm doing wrong. There is async call but it's wrappen in coroutineScope and it only crashes when I'm using Dispatchers.Main.
Any tips on where should I look to resolve this?

My coroutine structure:

viewModelScope.launch(<http://Dispatchers.IO|Dispatchers.IO>)
  withContext(Dispatchers.Default)
    coroutineScope
      async
      await - exception is thrown

OR

viewModelScope.launch(<http://Dispatchers.IO|Dispatchers.IO>)
  withContext(Dispatchers.Default)
    exception is thrown

Neither of those crash the app

[Filip Wiesner]

By "using Dispatchers.Main" I mean that the initial launch is viewModelScope.launch(Dispatchers.Main). The rest is the same

[louiscad]

Are you 100% certain the app doesn't crash? On recent Android versions, the force close popup can not be shown and the process be silently restarted. An easy way to check it is attach a debugger and let the app crash. If the app actually crashes, the debugger wil be disconnected @Filip Wiesner

[Filip Wiesner]

I can just continue using it and I don't see any closing animations. And yes, the debugger is still connected.
And even if it would crash silently, why would there be a different behavior when using .Main dispatcher?

[louiscad]

Does it happen with lifecycleScope in an Activity or only in viewmModelScope? Which AndroidX ViewModel KTX version are you using?

[Filip Wiesner]

I am using version 2.2.0 and I'll test the lifecycleScope. Gimme a sec

[Filip Wiesner]

Yeah, it's the same. I'll try to reproduce it in non-production project so I can share it

[Alex Vasilkov]

This code crashes as expected for me:

viewModelScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) {
    withContext(Dispatchers.Default) {
        throw RuntimeException("TEST")
    }
}

Are you sure that the thrown exception is not CancellationException or its subclass? 🙂

[Filip Wiesner]

Yeah, if I create new project and try the same structure, it does crash for me too 😞 I'll post here if I make any progress on this issue

[louiscad]

Might be related to a crash reporting library or something that deals with Thread.setUncaughtExceptionHandler in your project.

[Filip Wiesner]

It's definetly a project issue. I can call

GlobalScope.launch {
    error("")
}

inside a ViewModel and it still does not crash...

[Filip Wiesner]

Thanks for your help everyone 🙏 I'll probably spend my weekend debugging

[Filip Wiesner]

@louiscad You were right, it was because of Crashlytics

[louiscad]

Solely because of Crashlytics? Which version? I'm a bit surprised because I use Crashlytics and if I crash the app, well, it crashes anyway.

[Filip Wiesner]

My colleague found the "bug" and apparently it's because we didn't have enabled Crashlytics for debug (only for alpha, beta and prod). So maybe some Crashlytics handler was consuming the exceptions but not propagating them to default handler (maybe it was crashing? I am not sure)
I am still not 100% sure it's only because of Crashlytics becasue it's....weird but when my colleague enabled Crashlytics on debug, my unchanged code started crashing the app.
But we are still investigating...

[Filip Wiesner]

My other colleague just ran the app that wasn't crashing before and now it's crashing...

[louiscad]

Same version of CrashLytics?

[Filip Wiesner]

Same project - version 17.0.0

[louiscad]

Looks like a random bug in that version of CrashLytics