The next major version of Kotlin could automatical...

# language-proposals

[littlelightcz]

The next major version of Kotlin could automatically treat the "!!" operator either as warning or compile error, unless the particular line of code is annotated by @IWantNPEToBeThrownHere 🙂. Or perhaps the compiler could have a flag to turn this behaviour on.

[Dominaezzz]

Why? Might be better off with a linter I think but still... why?

[jw]

!! already implied you want an NPE to be thrown. That's literally the only behavior the operator provides.

[ian.shaun.thomas]

you can just search the project for those instances but if you really want a rule against them in your code that should be easy enough to add to detekt if that isn't already a feature (it seems what you are asking is for is a way to prevent them coming into your code base but it's not clear)

[Dico]

Yeah you haven't motivated your idea at all. My first question is - Why would anyone want this?? And then, why should it be forced upon everyone else?? And then, how are you going to implement it? Break all existing code?
Until you answer those questions, it's not a serious proposal.

[ian.shaun.thomas]

This isn't KEEP, I think it's fine to discuss a partial idea before having a complete proposal

[Dico]

Exactly, the idea is incomplete, and that is my point.

[ian.shaun.thomas]

#partial-language-proposals then?

[Dico]

I haven't said he shouldn't have posted it here, but I understand that this is something you can make up from "not a serious proposal".
Let me put it like this: what is the use case?

[orangy]

#IWantADifferentLanguageWhichIsLikeKotlinBut

[littlelightcz]

My idea behind this is that I have a feeling that people tend to misuse this operator a lot. Mostly it's probably because they've just started with Kotlin, but anyway I wanted to bring up a discussion whether Kotlin shouldn't be more stricter, or better said, "more educative" for the programmers to tell them from the start that this is not a preferred way to go 🙂.

The only use case for !! that I can think of, is when you actually need NPE to be thrown (probably for some super-legacy reasons) -- which is a very rare use case, I would say. Otherwise I think the null checks can always be done properly. From my perspective so far, 100% of the !! usages I've seen in the code on various places (be it github, or just some snippets people post on Twitter etc.) have been a misuse example.

On the other hand, if Kotlin would raise warnings or compile errors for this case, it would annoy this kind of people, who apparently don't care much about the NPE's anyway 🙂, so creating some linter rule would probably be a better solution for each team to choose how strict conventions they want to apply for themselves.

[cbruegg]

Actually, I think the !! operator is very important. True, you can use ? almost everywhere, but often you don't want your code to fail silently. When you expect something to be not null at some point, it's reasonable to use !!.

[littlelightcz]

Regarding the lint checks, perhaps this could be the part of a default IDEA lint check rules. For example I can remember that once I got "Inappropriate blocking call" lint warning, but I turned it off because in that case I was running a coroutine on an IO pool and I wanted to block/wait. So in case if there was a lint check for !! and it's use would be appropriate, then user could disable the check for particular part of code.

[littlelightcz]

@cbruegg There is just one problem with this and that is the "NullPointerException" doesn't tell you anything useful, but for example: "myVariable has not been initialized" does 🙂 . I think there are some nonNull assert functions for this use case which can do better than !!. Or another example: If you have multiple variables which can throw NPE on a single line of code - when the NPE is thrown, how do you find out which one has been null? ... It's not a big problem, but it's a complication that saves you some time if handled properly (= not using the !!) 🙂

[littlelightcz]

BTW there is another related idea that came to my mind. Regarding the use case that @cbruegg describes above, it would be nice to add some extension function that would behave in the similar way as checkNotNull(), but instead it would also print the checked variable name in the stack trace, so it would be clear from the first sight what has been null. It could be named e.g. .notNull() and could be used as:

val unsafeString: String? = "Shouldn't be null, but I what if I am wrong?"
println("Length is: ${unsafeString.notNull().length()}")

And in case the unsafeString would be null sometimes, the exception would be thrown in a fashion: IllegalStateException: The 'unsafeString' was expected to be not-null.

[littlelightcz]

I guess it's the same use-case as shown in https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/check-not-null.html except the error message is generated automatically by compiler (if possible)