Is `async { suspendFunc() }.await()` different fro...

# coroutines

[Quy D X Nguyen]

Is async { suspendFunc() }.await() different from suspendFunc() by itself?

[gildor]

mechanism of how it works is different

[gildor]

for example if async failed it will cancel parent Job (for non-Supervisor Job)

[gildor]

but on practice such pattern as: async { }.await() is always wrong, I don’t see any valid use case for it

[serebit]

functionally the same as withContext { } too

[gildor]

not the same, but to switch context withContext of course is preferrable

[Quy D X Nguyen]

So I can just call suspendFunc() and it'll be an async call?

[Quy D X Nguyen]

Just worried about accidentally blocking.

[gildor]

if you worry about blocking, check your suspendFunc() implementation

[gildor]

properly written suspend function shouldn’t block

[gildor]

also you always can use withContext(someDispatcher) { suspendFun } to use different dispatcher to be sure that it will not block your current coroutine

[Erik]

There is at least one use case for async-await on the same line:

https://medium.com/androiddevelopers/coroutines-patterns-for-work-that-shouldnt-be-cancelled-e26c40f142ad

Read just above and below the header 'What about something simpler?'

[gildor]

Okay, actually you right, I also used it a few times to make async not-cancellable

[gildor]

exactly for this use case, repository

[gildor]

So yeah, there is this use case, and it more clean imo than usage of non-cancellable coroutine on the same.
But it’s clearly not the case of original question