i'm getting some inconsistent crashes when I try to use

launch {}

in a button click handler:

java.lang.NullPointerException: Attempt to invoke interface method 'kotlin.coroutines.experimental.CoroutineContext$Element kotlin.coroutines.experimental.CoroutineContext.get(kotlin.coroutines.experimental.CoroutineContext$Key)' on a null object reference

Maybe the UI context is null when the activity is destroyed, and the coroutine is still running or something else having to do with the coroutine context passed...? You followed the ui guide?

it happens on a button click

@bj0 Could you post that code?

it's part of a large project, i'll see if i can isolate it

launch

tries retreiving a

Job

from the

CoroutineContext

that you pass to the

launch(context)

, it looks like that context is null sometimes.... maybe try a breakpoint or log there to check its value... and when the coroutine actually gets started.

I'm not specified the context, so it's using the default

CommonPool

, and I'm not touching any UI elements. I'm not worried about leaks because this fragment is embedded and doesn't get cleaned up until the app is closed

Maybe replace the

launch

with an

async { }.await()

there might be a hiddwn exception. Or if it's a race, maybe try a conflated actor like in the ui guide:

fun Node.onClick(action: suspend (MouseEvent) -> Unit) {
// launch one actor to handle all events on this node
val eventActor = actor<MouseEvent>(UI, capacity = Channel.CONFLATED) { // <--- Changed here
for (event in channel) action(event) // pass event to action
}
// install a listener to offer events to this actor
onMouseClicked = EventHandler { event ->
eventActor.offer(event)
}
}

that's commented out, it crashes with literally just

launch { delay() }

Its just that the error is funny, why should he coroutine context be null? Maybe this is a bug? But the actor might just be the workaround (maybe together with the parentJob cancellation), since that assures the dataCon.start() will only get called once and that it will set isStarted before the next press in considered...

yea I understand the comments you're making, they make sense but aren't related to the bug. I just did a quick

launch{}

because

.start()

is a

suspend

function, and I just need to fire it off. I plan on cleaning up that structure later, but I'm currently working on dealing with BLE details atm so I just needed a quick

launch