Let's say I'm developing a chat implementation. A Chat object (one to one communication with polling...

# announcements

[Edoardo Luppi]

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?

[Animesh Sahu]

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 😛

[Edoardo Luppi]

@Animesh Sahu oh yeah, you're right that they don't "suspend". If I'm not mistaken this would mean in e.g.

chat.connect()
chat.send(...)

The send call could happen while connect-ing is still in progress. Right?

[Animesh Sahu]

Yes...

[Edoardo Luppi]

@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

[Animesh Sahu]

Yeah, you cannot really call them from non-suspending context...

[Animesh Sahu]

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

[Edoardo Luppi]

@Animesh Sahu thanks!