Which convention is better? 1. ```checkNotNull(x)....

# codingconventions

[JP]

Which convention is better?
1.

checkNotNull(x).also {
    // do something like..
    it.prop = y
    // ...
}

2.

x?.apply {
    // do something like..
    it.prop = y
    // ...
} ?: throw IllegalStateException()

[Bornyls Deen]

I would favour `requireNotNull`/`checkNotNull` over a safe call and throw here because I think it more clearly and concisely expresses the hard requirement on x being non-null.

I'd probably go with either

requireNotNull(x)
x.prop = y

or

requireNotNull(x).apply {
    prop = y
}

depending on whether or not the scoping/return value of apply were required in your actual use case.

[Bornyls Deen]

I tend to reserve also for sneaking things with no side-effects like log statements into call chains.

[Bornyls Deen]

I prefer requireNotNull over checkNotNull because I think the name better reflects the consequences but it's worth noting that the exceptions that are thrown are different.

[JP]

Thanks for the opinion. Is a difference between requireNotNull and checkNotNull (also between require and check) only something conventional, such that one is used for checking function arguments, and one is used for checking other program states?

[Bornyls Deen]

No problem! I'm not aware of any particular convention to be honest... I guess it's just a matter of which exception type makes the most sense.

I haven't used checkNotNull but use requireNotNull mostly for things like reading from config files or validating POST requests. If my function required a non-null type I would just make that clear in the signature if possible 🙂

[Orhan Tozan]

@Bornyls Deen technically, log statements are side-effects😉.