Exception Constructor parameters getting mixed up in tryCopyException when thrown from rxJava Single

[rpmoore]

I have some code that after upgrading to v1.1.1 started to have some weird behaviors. I tracked it town to what I believe to be some assumptions made in the tryCopyException method in ExceptionsConstructor.kt

To explain more what exactly I'm seeing, I have an exception:

class IndexException(val name: String, t: Throwable? = null) :
    RuntimeException("Index $name does not exist", t)

If that exception happens to be thrown from inside of an rxJava Single, with an await() inside of a coroutineContext (we're migrating some code away from rxJava to coroutines), the exception will end up not being the same when thrown from the await()

For example:

import io.reactivex.Single
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.rx2.await
import org.assertj.core.api.Assertions.assertThat
import org.assertj.core.api.Assertions.catchThrowableOfType
import org.junit.Test

class IndexException(val name: String, t: Throwable? = null) :
    RuntimeException("Index $name does not exist", t)
class Exception_Testing{

    @Test
    fun test() {
        val error = catchThrowableOfType({
            runBlocking {
                Single.error<IndexException>(IndexException("indexName", Exception())).await()
            }
        }, IndexException::class.java)

        assertThat(error.name).isEqualTo("indexName") // this fails in my setup
    }
}

I'm using rxJava version 2.2.7, Kotlin 1.3.21, Coroutine 1.1.1

To get around this for now I've introduced an inline class to introduce a new type for the indexName.

This worked in v1.0.1 and I confirmed that the new behavior starts in 1.1.0

[qwwdfsad]

This is stacktrace recovery that is enabled by default in unit tests.
To workaround it, you can explicitly disable stacktrace recovery.

Your particular problem is fixed in 4ba30cd (in not-yet released 1.2.0)