Let's say I'm developing a chat implementation. A ...
# announcements
e
Let's say I'm developing a chat implementation. A Chat object (one to one communication with polling) create its own internal CoroutineScope with a new thread pool CoroutineContext. This avoid exposing suspend functions, and instead each is wrapped in scope.launch. Is this a good approach?
a
Depends, launching won't "suspend" the caller, so if that's the requirement use that, and exceptions will be handled through the ExceptionHandler which is set when you created the scope, otherwise it will be consumed. While on the other hand suspend function depends on the context of the caller (though you can always change context), and exceptions may propagate to the caller coroutine And well you can make the first one like this by returning the Job instance of the launched coroutine and caller may join() it if they wanted to, but it isn't the cleanest approach ­čśŤ
e
@Animesh Sahu oh yeah, you're right that they don't "suspend". If I'm not mistaken this would mean in e.g.
Copy code
chat.connect()
chat.send(...)
The
send
call could happen while
connect
-ing is still in progress. Right?
a
Yes...
e
@Animesh Sahu thanks. The problem with suspend-ing function is bridging them with other platform. For example using a
suspend send
from Java would be impossible being an additional
Continuation
parameter is generated
a
Yeah, you cannot really call them from non-suspending context...
https://stackoverflow.com/a/41561165/11377112 coroutines are basically compile-time synthetic sugar around the continuation, if you want to do interop they'll be very verbose and won't be easy to read/manage...
e
@Animesh Sahu thanks!