hi all, funny question but why did this function i wrote work? ```inline fun <reified T: Throwabl...

# getting-started

[abbic]

hi all, funny question but why did this function i wrote work?

inline fun <reified T: Throwable> assertThrows(clazz: KClass<T>, block: () -> Unit) {
    var exception: Throwable? = null
    try {
        block()
    } catch (e: Throwable) {
        exception = e
    } finally {
        assertTrue(exception is T)
    }
}

i used it expecting it to not work, but it successfully asserts T based on the clazz parameter i pass in, even though i dont actually use the clazz parameter in my function. is the runtime able to narrow down T based on the function parameter?

[abbic]

example

assertThrows(NoSuchElementException::class) {
    dao.getContractAccount(session)
}
assertThrows(NoSuchElementException::class) {
    dao.getContractAccount(session)
}
assertThrows(IllegalStateException::class) {
    dao.getContractAccount(session)
}

first 2 pass, last call fails

[Robert Williams]

Yep, that's exactly what reified does

[Robert Williams]

In fact you can remove clazz parameter and call it like

assertThrows<NoSuchElementException>() {

[abbic]

oh that makes sense

[abbic]

much better

[abbic]

i was so surprised at the inference coming from the fun parameter i stopped thinking about it 😛

[abbic]

oh of course, this is simply what happens when you define a value for a generic parameter, and the <Type> gets greyed out as its inferred from the definition itself

[CLOVIS]

Note that this function is already in the standard kotlin.test library, IIRC it's called assertFailsWith or similar

[abbic]

ah ok, some searches didnt turn up anything useful and junit5's stuff wasnt so nice (wouldnt work with suspend funs)

[CLOVIS]

https://kotlinlang.org/api/latest/kotlin.test/kotlin.test/assert-fails-with.html

[abbic]

oh my project doesnt have that dependency for some weird reason

[abbic]

appreciate it!

[CLOVIS]

It's not added by default, which platforms are you targetting?

[abbic]

android, no i wasnt expecting it to be there by default but i work on a large and mature project

[abbic]

and would have expected someone else to have gotten around to this sooner (because of all the junk that is already present)

[Robert Williams]

Most android projects start with junit and never add kotlin.test

[Robert Williams]

They mostly overlap but I think it's fine to use both together

[ephemient]

kotlin-test assertions have contacts and JUnit assertions don't, so in some ways kotlin-test is nicer to use, but except in multiplatform projects I tend to use JUnit assertions anyway because they're more complete and using both can be confusing