Czar12/26/2018, 8:26 AM
// hibernate is used for illustration, because it recommends to use nullable IDs for entities val entity: MyEntity = hibernateRepository.requireEntityById("some-id") private fun String.doSomethingWithId() // 1 checkNotNull(entity.id).doSomethingWithId() // 2 entity.id!!.doSomethingWithId()
louiscad12/26/2018, 8:27 AM
gildor12/26/2018, 8:28 AM
louiscad12/26/2018, 8:28 AM
Czar12/26/2018, 8:31 AM
is almost invisible when reading code and while for cases like this one it is probably ok, it makes a habit of substituting
in other situations, too, which isn't desirable. By the way I've updated the code, because 1) I made a mistake when writing it first time. 2) to make it obvious that repository either returns a non-null entity or throws.
gildor12/26/2018, 8:39 AM
Czar12/26/2018, 9:02 AM
miha-x6412/26/2018, 9:03 AM
Czar12/26/2018, 9:05 AM
tipsy12/26/2018, 9:28 AM
Czar12/26/2018, 9:47 AM
tipsy12/26/2018, 10:02 AM
it makes a habit of substitutingbut that's very subjective. i always usewith
checkNotNullin other situations, too, which isn't desirable.
when i'm sure, and but never otherwise.
is a statement; you're saying "this thing is never null". by using
you're saying "this thing might be null", which is wrong.
Czar12/26/2018, 10:38 AM
by usingNope,you're saying "this thing might be null", which is wrong.
is indicative of a bug, if state is illegal then it should never be achieved. So
also states that the thing is never
. Note that never is not a real thing in software, it actually means never in correctly working code that is correctly accessed
For example, this [IllegalStateException] would be the exception to throw if the caller attempted to use some object before it had been properly initialized.
tipsy12/26/2018, 11:08 AM
, i see that as a promise from whoever wrote the code that the id will "never" be null i don't really care if the code throws
. to me,
more clearly shows the intent of whoever wrote the code
, if not for these cases?
Czar12/26/2018, 11:12 AM
, I do not like
, I think it was a mistake to include double bang in Kotlin language 🙂
tipsy12/26/2018, 11:13 AM
Czar12/26/2018, 11:21 AM
if i open a project and read
`checkNotNull(myId)`/`requireNonNull(myId)/etc` i will (mistakenly?) think the id might be null
does not signify possibility of something being
according to both
documentation, it signifies that if at this point the argument is
then there's something wrong in the application, it doesn't work like it was intended and it is a bug which should be fixed. Whereas
is more like, here, compiler, I promise it's not null, leave me alone, I want to forget all about it. And this wish is granted, because when reading code,
is almost invisible 🙂
tipsy12/26/2018, 11:26 AM
turns out it doesn't, but i didn't know that (neither did "darksnake" in the linked thread). "checkNotNull" reads like "this thing might be null". if you have 5 teams working on this codebase i suspect some of your devs might think like me and darksnake.does not signify possibility of something being
aarjav12/26/2018, 4:26 PM
is used because there is some state in the current context that needs to be checked for null. If it breaks, it implies bug in current class or caller.
means one of the methods or classes being used by current code returns a non null. If it breaks, it implies bug in method used (
). Hopefully with Kotlin contracts we will be able to have contracts on
properties of arguments as well though I'm not sure since sometimes they're calculated. Imo
should be used as little as possible and should be such that eventually a contract or some smarter typing can make it obsolete in the future.
Czar12/26/2018, 5:14 PM
@aarjav I mostly agree, although I'm a bit more strict and currently don't allow
at all for my team.