https://kotlinlang.org logo
Title
b

bj0

08/23/2018, 5:59 PM
so we should be catching
JobCancellationException
instead of
CancellationException
?
e

elizarov

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.
b

bj0

08/23/2018, 6:04 PM
ah, ok
e

elizarov

08/23/2018, 6:04 PM
Btw, what is your use-case for catching it manually?
b

bj0

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
        }
e

elizarov

08/23/2018, 6:07 PM
What do you send to statusChannel if it crashes with (other) exception?
b

bj0

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.
e

elizarov

08/23/2018, 6:10 PM
I’d refactor it as:
catch (t: Throwable) {     statusChannel.offer(t.toStatusMessage())
  throw t
}
b

bj0

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?
e

elizarov

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.