Stack trace recovery

Look at the example below

fun main(args: Array<String>) = runBlocking {
    xxx()
}


suspend fun xxx() {
    delay(100)
    throw Exception()
}

The execution of the code results to an exception with the incomplete stack trace.

Exception in thread "main" java.lang.Exception
	at TestKt$xxx$1.doResume(Test.kt:20) // throw Exception()
	at kotlin.coroutines.experimental.jvm.internal.CoroutineImpl.resume(CoroutineImpl.kt:54)
        ....
	at TestKt.main(Test.kt:13) //  runBlocking

The stack is starting from the bridge function and completes with the last continuation. All the intermediate calls are missing.

The problem makes it difficult to debug the app because it is not possible to determine the true continuation caller. The stack trace of an exception, thrown from a coroutine, becomes useless.

[matejdro]

How about this one?

fun main(args : Array<String>) {
    runBlocking {
        getData()
    }
}

private suspend fun getData() {
    suspendCoroutine<Unit> { continuation ->
        thread {
            continuation.resumeWithException(Exception("Test Exception"))
        }
    }
}

Running this code will produce this exception:

Exception in thread "main" java.lang.Exception: Test Exception
	at TestKt$getData$2$1.invoke(Test.kt:14)
	at TestKt$getData$2$1.invoke(Test.kt)
	at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)

This exception only works if getData() is called from one place in my application. Otherwise it is very unhelpful, since I have no way of knowing where this method was called.

This is especially frustrating when coroutines is wrapped around 3rd party library such as Google Play services’s Task API. All Google Play code is completely obfuscated, so exceptions will contain only jibberish class names without any hint for where this code is called from.

However, IDEA has “async stracktraces” features where it does capture this kind of information in debug mode.

This is helpful if developer can reproduce the crash in the IDE. But more often than not crashes arrive via crash reporting tools where developer can only see the exception.

[elizarov]

Here is an update on this issue. Under the most recent version of Kotlin compiler (1.1.4-eap-33) the topic-starter’s example code produces the following stack-trace:

Exception in thread "main" java.lang.Exception
	at TestKt.xxx(Test.kt:10)
	at TestKt$xxx$1.doResume(Test.kt)
...
	at TestKt.main(Test.kt:4)

As you can see, named suspending functions now execute directly in the the correspondingly named functions on JVM, so the top of the exception stack-trace directly refers to the name of the corresponding suspending function that threw exception in the source code.