so we should be catching `JobCancellationException...

# coroutines

[bj0]

so we should be catching JobCancellationException instead of CancellationException?

[elizarov]

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.

[bj0]

ah, ok

[elizarov]

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

[bj0]

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

[bj0]

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

[elizarov]

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

[bj0]

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

[bj0]

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.

[elizarov]

I’d refactor it as:

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

[bj0]

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

[bj0]

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?

[elizarov]

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