so we should be catching `JobCancellationException` instead kotlinlang #coroutines

08/23/2018, 5:59 PM

so we should be catching

JobCancellationException

CancellationException

08/23/2018, 6:03 PM

It does not matter much if you don’t integrate with Java

CompletableFuture

-based async code. We only throw

JobCancellationException

, but support any

CancellationException

for interop with Java.

08/23/2018, 6:04 PM

08/23/2018, 6:04 PM

Btw, what is your use-case for catching it manually?

08/23/2018, 6:05 PM

i've logged it in the past, but for my current application I change status: ```

} catch (e: JobCancellationException) {
            statusChannel.offer(ConnectionStatus.Disconnected)
            throw e
        }

08/23/2018, 6:07 PM

What do you send to statusChannel if it crashes with (other) exception?

08/23/2018, 6:07 PM

catch (t: Throwable) {
            statusChannel.offer(ConnectionStatus.Error("exception thrown: ${t.message}"))
            throw t
        }

my general pattern for doing communication so far has been to have a

run

function that connects and then suspends while the connection is active. It can then be disconnected by canceling from the caller.

08/23/2018, 6:10 PM

I’d refactor it as:

catch (t: Throwable) {     statusChannel.offer(t.toStatusMessage())
  throw t
}

08/23/2018, 6:10 PM

not sure if there's a better way, but this way I don't have to keep track of jobs inside my class

you'd just wrap a

when(t)

in an extension method instead of multiple

catch

blocks? if it's only used in one location whats that buy you? readability?

08/24/2018, 6:43 AM

Yes. Readability. This way I immediately see that a status message is sent to the status channel on any exception.