Is there any way to handle dropped return values from a suspending coroutine? Say I do this:

fun processImage() {
  val file = createFile()
  try {
    // Do stuff with the file
  } finally {
    file.delete
  }
}

suspend fun createFile(): File = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
  return File.createTemporaryFile("foo", "temp")
}

There is a case where

createFile

has finished but

processImage

has not yet been resumed. If during this time the job is cancelled we’ll never get a chance to clean up the file. Is there a way around this?

Would this solve your issue?

fun processImage() {
  val file : File? = null
  try {
    file = createFile()
    // Do stuff with the file
  } finally {
    file?.delete
  }
}

No, it would have the same result since

createFile

never actually “returned” a file

Right. The

File

is only returned from the withContext lambda parameter, but not yet from createFile

I could use the unconfined dispatcher I suppose but then I’d lose the dispatcher of the parent

Did you see that coming? Or did it fall on your feet?

How about this:

suspend fun processImage() {
    useTemporaryFile { file ->
        // do stuff with the file
    }
}

suspend fun <R> useTemporaryFile(body: suspend (File) -> R) : R = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
    val file = createTempFile("foo", "temp")
    try {
        withContext(Dispatchers.Default) {
            body(file)
        }
    } finally {
        file.delete()
    }
}

this should always delete the file

Almost brilliant. Except we want to go back to where we came from, not to the default dispatcher

This was just an example to illustrate the general problem, the creation of the resource cannot be called in a blocked way

understood. But i think @trathschlag's approach is one to remember for this general case

@uli if you just want to keep the original context, you could also use the magic

coroutineContext

extension property:

suspend fun <R> useTemporaryFile(body: suspend (File) -> R): R {
    val outerContext = coroutineContext
    return withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
        val file = createTempFile("foo", "temp")

        try {
            withContext(outerContext) {
                body(file)
            }
        } finally {
            file.delete()
        }
    }
}

but I'm still not sure if there are any pitfalls regarding this. and for the general problem: what about

suspend fun processImage() {
    val outerContext = coroutineContext

    withContext(NonCancellable) {
        val file = createFile()

        try {
            withContext(outerContext) {
                // do something with file
            }
        } finally {
            file.delete()
        }
    }
}

still not the most intuitive

The longer I think about it, I come to the conclusion, that

withContext

should be designed to prevent canceling while returning to the calling context. The current design allows for cancelation while there is no owner for the result object, allowing for it to be lost. This is 1) implicit and 2) surprising which are two things that Kotlin typically tries to avoid with it's design

See this recent comment: https://github.com/Kotlin/kotlinx.coroutines/issues/962#issuecomment-466365797

@uli This behavior of

withContext

is designed on purpose. In a UI app, when we return back to the main thread we want to be sure that the UI is not destroyed (job is not cancelled) before we attempt to manipulate it.

The app could also crash so I still have to clean up old files so not a huge issue, but could be a problem with other closable resources such as sockets and input streams. It could be great if there an option to have a block that would be called when the Coroutine would be resumed but is canceled

We used to have it. We can have a separate version of

withContext

(maybe) with this kind of behavior.

The problem is not specific to

withContext

though but rather all functions that actually suspend

The problem is not specific to functions that suspend, but to all functions that can throw exception.

Fair enough, but it’s a problem with

suspendCoroutine

for example

this kind of pattern:

val r = acquireResource()
try { ... } finally { r.close }

is inherently tricky. You have to make there is nothing between

acquireResource

and

try

and the implementation of

acquireResource

need to have extreme care for exceptional cases.

Perhaps the solution is to have a try-finally pattern with Coroutines

Yes. We definitely need a better try/finally for coroutines. We have a similar problem with `launch`:

val r = acquireResource() 
launch { 
    try { ... } finally { r.close() }
}

It will not work, because launch may not even start.

The launch example would when using ATOMIC though?

Yes. Not a nice solution, but works. We used to have

CoroutineStart

paramater for

withContext

, too, but dropped it.