Is there a better way to only send a "completion m...

# coroutines

[taer]

Is there a better way to only send a "completion message" on a successful completion of flow when using a cancel? in this case, batchMeetings is my own impl of flow.chunked()

var caughtException = false
        val batches = batchResults(inputFlow, chunkSizePerMessage)
            .map { createResults(it) }
            .catch {
                caughtException=true
                emit(Results.TerminateWithError(it))
            }
        emitAll(batches)
        if(!caughtException) {
            emit(Results.SuccessfulFinish())
        }

Ideally, the Successful finish would only be sent on no exceptions from the upstream flow. That var caughtException seems ugly. Is there a cleaner way?

[elizarov]

What's the use-case for that?

[elizarov]

Why would you need to emit a message on cancel? What code is going to process that message and how if it is being cancelled?

[taer]

The flow emits a sealed class of (data, error, Success(completedAt). So a normal flow would be
D1, D2, D3, D4, Complete(timeStamp)
and error case
D1, D2, D3, Error

[taer]

Would it be cleaner for the terminal collector to have the catch and eliminate the Error type all together maybe?

[elizarov]

error's no problem. But why do you need to handle cancellation?

[elizarov]

If you just need to handle error just do this:

flow
    .onCompletion { emit(Results.SuccessfulFinish()) }
    .catch { emit(Results.TerminateWithError(it) }

That's it

[taer]

Wait.. that's it? I had them in the opposite order.. the catch in front on the onCompletion

[taer]

and I was getting both

[taer]

no.. It's still sad. It's actually emitting
D1, D2, Success, Fail

[taer]

letting the error go though w/out mapping to a result class actually worked pretty well. Just mainly curious if there is an onCompletion that wouldn't fire on error case

[taer]

oh.. that onCompletion is given the exception if it happened.

[taer]

😉 Thanks!

[elizarov]

Yes. You can do .onCompletion { if (it != null) emit(...) }.

[elizarov]

We were actually thinking on having a separate operator just for "successful completion" but have not figured out a good name for it that people would not be confusing with onCompletion

[taer]

only input would be onError() and onSuccess(). That's not obvious though still