:thinking_face: interesting. So bottom line is bet...
# coroutines
p
🤔 interesting. So bottom line is better not mess with it.
l
I usually catch
CancellationException
first and rethrow it, then catch other
Exception
types or
Throwable
.
p
Makes perfect sense. However, if this propagation is so important for the whole coroutine tree to work properly. Don't you think that this boilerplate should be part of the coroutine compiler job. Honestly don't even like the fact of categorizing the Cancellation as an Exception. But well I bet there's other good reasons for this design.
l
I would have the issue of being implicit. I think it'd be better to warn about it with an IDE intention when in a suspending or inline function.
p
At the least yep.
l
That's a good freature request to submit on kotl.in/issue. Do you want to do it?
p
Oh pretty cool! You mean on the IDE side or in the Coroutine framework side On the Coroutine framework side it looks like an already conceptualized and establish pattern. Don't think they will be open to modifications. On the IDE side would be so much beneficial. The link is asking me for authorization. Should I create an account?
l
It'd be an IDE inspection. Yes, I personally created an account with Google Sign-in.
p
Cool let me find the time for doing so. I might DM you before opening for a quick review.
👍 1
Hey man! @louiscad I just file the issue on JetBrains. Check it here: https://youtrack.jetbrains.com/issue/IDEA-224078?project=IDEA&summary=Warn%20developers%20when%20a%20CancellationException%20is%20caught%20and%20not%20re-thrown%20inside%20CoroutineScope.&description=What%20steps%20will%20reproduce%20the%20issue%3F%0A1.%20%0AInside%20a%20CoroutineScope%20place%20the%20following%20code:%0A%60%60%60%0Aval%20job%20%3D%20scope.launch%20%7B%0A%09%09%09%0A%09try%20%7B%0A%09%09%0A%20%20%20%20%20%20%20%20%20%20%20%20%20while%20(true)%20%7B%0A%09%09%20%20%20%20channel%3F.send(inMsg)%0A%09%20%20%20%20%7D%0A%09%09%09%09%0A%09%7D%20catch%20(e:Throwable%20)%20%7B%0A%09%09e.printStackTrace()%0A%09%7D%0A%09%09%09%0A%7D%0A%60%60%60%0A%0A2.%20After%20some%20time%20called:%0A%0A%60%0Ajob.cancel()%0A%60%0A%0A3.%20The%20propagation%20of%20the%20**CancellationException**%20gets%20interrupted%20by%20the%20general%20try%2Fcatch%20block.%0AIt%20potentially%20will%20corrupt%20the%20Structure%20Coroutine%20state.%0A%0AWhat%20is%20the%20expected%20result%3F%0A%0AIntelliJ%20should%20**warn**%20the%20developer%20about%20the%20fact%20of%20catching%20the%20CancellationException%20and%20not%20re-throwing.%0A%0ASomething%20like:%0A%0A%60%0A%2F%2F%20WARNING:%20Catching%20a%20super%20class%20of%20CancellationException%20requires%20handling%20the%20case%20when%20the%20Exception%20is%20a%20CancellationException%20an%20re-throw%20it%20in%20such%20a%20case.%0A%60&c=Subsystem%20Code%20Analysis.%20Inspection&c=tag%20Star
l
@Pablichjenkov It's not in a CoroutineScope but in a suspending function, and in inline lambdas (as these can be inlined in suspending functions)
p
Good, let me edit it. I have the bad habit of calling the lamba passed to the coroutineBuilder
scope
but is not.
Changed the title to: Warn developers when a CancellationException is caught and not re-thrown inside a suspending function or in inline lambdas (as these can be inlined in suspending functions)
l
Good!
You can also mark it as a feature rather than a bug.