Is there an equivalent of `check` that would take a supplier lambda for the case when the check pass...

# getting-started

[poohbar]

Is there an equivalent of check that would take a supplier lambda for the case when the check passes?

[Andreas Sinz]

like run this lambda on success, otherwise throw an exception?

[Nikky]

something.takeIf { check(it) }?.run(lambda) ?: throw Exception()

[Nikky]

like so ? should be simple enough as a extension function for your needs

[poohbar]

@Andreas Sinz yeah
@Nikky check() does not return Boolean

[Andreas Sinz]

I'm not aware of any function in the stdlib, but its trivial to write your own:

inline fun checkOnSuccess(value: Boolean, onSuccess: () -> Unit) {
    if(value) 
        onSuccess() 
    else 
        throw IllegalStateException()
}

[Pavlo Liapota]

Isn’t it equivalent to this?

check(value)
onSuccess()

Everything after check() is executed only if value is true, otherwise exception is thrown.

[Ruckus]

@poohbar If you want the functionality of check (i.e. continue on true, throw on false), what @Pavlo Liapota suggested should do the trick. If you just want to return a Boolean, you're already passing in a Boolean so what does a new function get you over if?

[poohbar]

yeah it works great, i just wanted to use it in a method without full body

[poohbar]

so i needed to have just one statement

[poohbar]

i had:

fun foo() = if (condition) value else throw IllegalStateException()

[poohbar]

and i wanted to use check() instead

[Ruckus]

Any particular reason why it needs to be disembodied? I've noticed many times people code themselves into a corner in Kotlin trying desperately to fit separate logical statements into one line.

[poohbar]

no reason, I was just wondering

[poohbar]

i am not a big fan of how the syntax for property getters work and they look a bit better if they don't have a body

[poohbar]

val value: Type = initialValue
    get() {
        // do something here
    }

this just looks odd to me.. too much indentation

[Ruckus]

Interesting. I've actually always found it cleaner than other property enabled languages.

[Ruckus]

With one exception: field

[Ruckus]

I really hate field. Personally I think it would make far more sense in the setter to use the properties name as the backing field, and if you do want to call the setter or getter recursively, use this.<propertyName>.

[Ruckus]

But that's just me 🙂

[poohbar]

oh yeah that would be way better, agreed