It seems like `CoroutineExceptionHandler`s are ignored for exceptions thrown from a coroutine `launch`ed with a parent

Job

from a

runBlocking

scope. Changing the dispatcher doesn’t seem to matter, and coroutines `launch`ed from

GlobalScope

execute the handler as I’d expect. I can’t see any documentation about this or figure out how this makes sense. E.g.

fun main(args: Array<String>) {
  val handler = CoroutineExceptionHandler { _, exception ->
    println("Caught $exception")
  }

  runBlocking(handler) {
    val job = launch {
      // This exception is thrown from runBlocking, and not seen by handler.
      throw AssertionError()
    }
    job.join()
  }
}

If you change that to the following,

handler

gets run:

runBlocking {
  val job = GlobalScope.launch(handler) {

Is this behavior by design?

Hello everyone I am stuck on a kotlin coroutine. Appreciate if someone can help me on that. I am launching a coroutine that after a specified delay display a counter value on the screen. job = launch(UI) { var count= 0 while (true) { textView.text = "${count++}" delay(200L) } } } Now on screen rotation I want UI keeps getting updated with correct counter value. Does someone has any idea how to resume the job on configuration(e.g. screen rotation) change?

I might have missed this before or in the documentation, but are there best practises to handle the new CorotuineScope in fragments (in particular where to attach and cancel an instance of a Job)? Are onAttach/onDetach of the parent activity a good choice? Probably it's more a question for the Android channel, but i've posted here because it is coroutine-related

I'm trying to update some library code to coroutines 0.26 and I am noticing some boilerplate patterns. If I'm not mistaken, we want every class that launches its own coroutines to be a

CoroutineScope

, unless the coroutines created by that class should always act globally for the full lifetime of the application. This means every class that launches coroutines should be created through an extension function on

CoroutineScope

like

CoroutineScope.MyClass()

. So

MyClass

needs a constructor that takes scope as a parameter, then we need to make an extension function for

CoroutineScope

that is an exact copy of the constructor for

MyClass

except it uses

this

from

CoroutineScope

instead of taking scope as a parameter. If there is a class with several constructors that each have several parameters this can be really annoying and a bit hard to maintain. Is there a better way for me to be scoping the coroutines launched by classes?

Is there an idiomatic way to override the default dispatcher for unit tests? or would this be considered bad practice, and typical injection preferred?

Well, I'm really glad that I joined KotlinConf workshop in Amsterdam with @elizarov , Hope version 0.26.0 "structured concurrency" will be presented😄

I’m curious about the example in the coroutines guide for structured concurrency on Android :

abstract class ScopedAppActivity: AppCompatActivity(), CoroutineScope {
    protected lateinit var job: Job
    override val coroutineContext: CoroutineContext 
        get() = job + Dispatchers.Main
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        job = Job()
    }
        
    override fun onDestroy() {
        super.onDestroy()
        job.cancel()
    } 
}

https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md#structured-concurrency-lifecycle-and-coroutine-parent-child-hierarchy It seems to me that this example is needlessly complicated. The following would work just as well.

abstract class ScopedAppActivity: AppCompatActivity(), CoroutineScope {
    override val coroutineContext: CoroutineContext = Job()

    override fun onDestroy() {
        super.onDestroy()
        coroutineContext[Job]?.cancel()
    }
}

Since

Dispatchers.Main

is the

ContinuationInterceptor

used when none is available in a

CoroutineContext

, this should yield the same result. Is there something I’m missing?

@cb has a nice Gist on using

CoroutineScope

with

LifecycleObserver

so you can avoid having to use inheritance

I have a strange issue, but I am not sure if it is related to coroutines. But I have the following unit test:

@Test fun testActor() {
  val testActor = actor<String> {
    println(channel.receive())
  }

  testActor.sendBlocking("CHANNEL-MESSAGE")
}

When I run this locally on my machine I see

CHANNEL-MESSAGE

being printed. But when I build this with docker it is never received. My

Dockerfile

looks like:

FROM maven:3.3.9-jdk-8
COPY . project/
WORKDIR project
RUN mvn clean package

I used version

3.3.9

which is the same on my local machine. With docker it actually freezes on the

sendBlocking

. Anyone a clue how this is possible?

Here if

unsafeMethod

fails it will make the parent job fail, which basically mean a crash of the UI componenent (any working coroutine will be cancelled and further action would no longer work) Of course I could encapsulate the call in

try-catch

. But it is a bit boilerplate and easy to forget. (here it is obvious, but what about unexpected exceptions?) How could I launch a child coroutine in a way that it does'nt propagate the failure to the parent?

I'm getting a

call to 'resume' before 'invoke' with coroutine

error, but I'm having a hard time figuring out what's causing it and I can't seem to isolate it (though I can reproduce in this single environment). Any suggestions on how to track it down?

Are there examples on how to handle exceptions during

launch

blocks? I have a method created like so:

suspend fun <T> Deferred<T>.awaitOrRedirect(context: Context): T? =
    try {
        await()
    } catch (e: Exception) {
        logd("Error, redirect to Login")
        LoginActivity.launch(context)
        null
    }

But the errors seem to just pass through and cancel the coroutines altogether without launching the activity. To give more details, I’m building for Android, and I’m using

CoroutineScrope

within the activity that is calling the method. I’m using

launch

as it is used for most of the example code, and it looks like the only difference with

async

is that

async

cancels the parent and returns a deferred value. I also see that there are `CoroutineExceptionHandler`s, though I’m not sure if that is the right fit here.

Hello, I would like to replace RxJava with Kotlin coroutine. I wrote it in RxJava as follows.

kotlin
    api.fetchPersons()
        .subscribeOn(scheduler)
        .subscribe(
            { persons ->
              showPersons(persons)
            },
            { e ->
              showErrorDialog(e)
            })

I enclosed with try catch to do the same on kotlin coroutines as follows. But in this case CancellationException did not go to parents job, so I thought that it would be in an invalid state. Even if CancellationException is caught by the user, the outer block is not just canceled, is there no problem? Is it fine just like this?

kotlin
    launch { 
      try {
        val persons = api.fetchPersons() // suspend function
        showPersons(persons)
      } catch (e: Throwable) {
        showErrorDialog(e)
      }
    }

Hey, how do you manage to dispatch the progress of a long running

suspend fun

? I'd like to see the approaches you prefer

I usually just pass lambda for progress. Much less overhead than channel. But you can get callback on a different thread, so should handle this case

so apparently user of my program encounters deadlock issues rnadomly in my program, apparently in a area of the code where i use coroutines and channels but the worst is.. i cannot manage to reproduce it with the same input data on my hardware would i be able to use visualvm to see where it is blocking itself? i also did not quite rule out that ktor-client-cio is not at fault, but again no idea how to test that :thread-please:

Why do I have to use

coroutineScope {  }

only inside another coroutine or a suspending function? What's wrong with

fun main() = coroutineScope { <do the majic> }

? Do I need

runBlocking{}

there? What's the meaning of

runBlocking

with scoped coroutines if scopes wait for their children?

coroutineContext

is a top level property that can be accessed from suspend functions. I suspect that it does this under the hood:

get() = suspendCoroutineUninterceptedOrReturn { cont -> cont.context }

Can a

suspend

function somehow find out in which dispatcher/executor is it running now?

I have a class that does file download. I have a function that triggers a download, and returns LiveData with the download progress. For each new call it would return new LiveData and it works nicely when I download 1 file. Now I want to launch new coroutine for each file download under the same scope, so I can cancel all at once if I want to. Can someone help with different ways to do this? or maybe what would be the best way? So I need to launch separate coroutine for each new call to the function, and add it under the same context.

📣 📣 📣

kotlinx.coroutines

version

0.26.1

. Asynchronous Main dispatcher on Android, various bug fixes and improvements. See https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.26.1

Any resources for implementing coroutines+ retrofit 2 especially when one wants to chain multiple calls

On

0.26.0

I see in the release notes that

Dispatchers.Default

is now default dispatcher, but I had some existing code that was roughly

runBlocking { someList.map { async { <do stuff with 'it'> } }.map { it.await } }

that previously ran on

CommonPool

by default, but after the upgrade is constrained to the main thread. Guess I'm missing some detail around the structured concurrency changes...

@bj0 you don’t need an extra

coroutineScope

. The

launch

already provides one.

when you create a

CoroutineScope

object, is there a way to wait for it to finish (like

coroutineScope

waits)?

In the structured concurrency example for Android (https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/coroutines-guide-ui.md#structured-concurrency-lifecycle-and-coroutine-parent-child-hierarchy),

Dispatchers.Main

is added to the

job

to make it so the dispatcher used for child coroutine builders will be

Dispatchers.Main

(correct me if I'm wrong). Which dispatcher is used if the

+ Dispatchers.Main

portion is omitted?

override val coroutineContext: CoroutineContext 
    get() = job

0.26.1

seems available but not

0.26.1-eap13

, is that expected ?

Where is

future

function gone? There is no

GlobalScope.future

.

maybe I should reference a special library to make it work?