-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CoroutineExceptionHandler installed in top(-most) scope not always used. #1157
Comments
When you call I think your test cases therefore make sense. In However, if a coroutine fails and has a parent in its scope, then it never invokes its uncaught exception handler, it propagates to its scope. I think that explains For I think it's interesting to conceptually think that the coroutine propagates its exception to its scope rather than to its parent. It's the scope that can either have a parent capable of handling the exception or not, which determines the behavior. |
@MartinDevi Thank you for your answer. Reading your answer, I think my misunderstanding was based on mixing up 'parent-child relationship' and 'overwriting coroutine-context element'. For example, In I must say, it is tricky to understand it all... easy to forget and make mistakes.... :) |
Could you please add some more examples using try/catch to capture some of the errors inside nested coroutines? We've been trying to understand the story about async error handling for a while too. |
@pakoito
Hope this helps. |
This part of coroutines machinery is not well documented in details. We are currently working internally on the advanced exception handling mechanisms that will be easier to use and reason about.
|
Thank you @qwwdfsad ! About point (2). From that test it seems that the |
Code:
This is a bit more advanced case. You are trying to formulate the single rule like "the handler from the topmost scope is used" and that's where the confusion comes from, the actual rule has more than one variable (parent scopes, their context and whether a parent is able to handle an exception) |
With the Context being a set, as an arbitrary suspend function, could I override the parent handler? or as a child coroutine? |
@pakoito Context is an immutable set. It cannot be affected by children of by anything at all after coroutine is created. If a coroutine is a child, then its CEH does not matter, since it would never use it itself. |
Okay, that makes sense. Now, correct me if I'm wrong. Only the creator is allowed to install new CEHs and if you want your own handling you have to use Also, will any new |
Yes.
Yes.
All builders inherit all context keys from the scope. However, one correction here: If you you do |
I have this example code-snippet:
My questions are:
CoroutineExceptionHandler
, it will be used, otherwise, the exception is thrown up the call-stack?CoroutineExceptionHandler
used instead? Only if no such top scope can be found, the exception is thrown up the call-stack.test4()
not use thexHandlerParent
, since that is theCoroutineExceptionHandler
of the top and top-most scope?The text was updated successfully, but these errors were encountered: