-
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
recoverStackTrace causes nested exceptions #3714
Comments
Thank you for the report! The actual problem is in this line: kotlinx.coroutines/kotlinx-coroutines-core/jvm/src/internal/ExceptionsConstructor.kt Line 44 in 3fc1c20
|
These two constructors should be identical, something is going completely wrong here |
…(cause)' constructor. And restore the original behaviour. After #1631 this constructor's recovery mechanism was broken because 'Throwable(cause)' changes the message to be equal to 'cause.toString()' which isn't equal to the original message. Also, make reflective constructor choice independable from source-code order Fixes #3714
The test that was implemented in #3731 seems to have some incorrect asserts that are actually testing that the error is still happening. The asserts in the test are:
which asserts that the error is: But what the thrown error should actually be is:
So it seems like this issue is not yet solved, and I'm still running into this issue in my dependant code after updating to 1.7.0. |
Describe the bug
When throwing an exception in a coroutine scope it sometimes becomes nested one level too deep in the enclosing exception.
For example, if I throw a:
TestException(IllegalStateException("test"))
(a TestException with a cause of IllegalStateException with a message), then the coroutine scope will throw an exception that is:TestException(TestException(IllegalStateException("test")))
.Provide a Reproducer
The following test will fail as a result of this bug:
I can get this test to not fail by changing the order of the constructors in the class to:
But I don't think this is actually a good solution as it shouldn't matter the order of the constructors in my exception, it should work the same way regardless.
I think the issue is at this line where the wrong constructor is being selected (the string constructor instead of the cause constructor).
The text was updated successfully, but these errors were encountered: