<@U2E974ELT> is there a reason Job doesn't expose ...

# coroutines

[sitepodmatt]

@elizarov is there a reason Job doesn't expose parentJob : Job?. My use case would be logging/debugging aids - wanting to log the path of jobs to the root when one fails, a job trace vs a stack trace. Ive managed to hack around it with this evil code but I wondering if there a strong reason for concealing

@UseExperimental(InternalCoroutinesApi::class)
fun Job.getParent() : Job? {
    return (AbstractCoroutine::class.java as Class<*>)?.
        getDeclaredField("parentContext")?.
        also { it.isAccessible = true }?.
        let { it.get(this) as? CoroutineContext? }?.
        let { it[Job] }
}

[sitepodmatt]

a primitive example of a use case https://gist.github.com/sitepodmatt/70a8561abad20a3a62b0b0b99f9f9e08

[elizarov]

Two reasons. One is encapsulation. Parent is Job’s internal detail. If I gave you reference to my child job, then you should be able to cancel it, but not walk up to its parent (me) and cancel me. The other one is we are looking to potentially “late binding” to a parent in the future, which makers “parent” property mutable and thus harder to reason to about.

[elizarov]

For debugging, I’d suggest to take a look here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/core/kotlinx-coroutines-debug/README.md We are considerably enhancing these debugging facilities for an upcoming release.

[sitepodmatt]

Okay thanks, will take a read

[sitepodmatt]

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-debug/kotlinx.coroutines.debug/-debug-probes/job-to-string.html 🎉