Today I decided to try “Kotlin” from the “JetBrains” brand, but in less than 5 hours I realized that nullpointers can jump like fairground bullets.
When I heard the “null safety-?”, I thought for a moment all those programmers that from now on, they will not really need to check if their “object” is going to be null or not, because if you control it automatically with “?”, they will stop paying attention if null arrives or not. (For example, those programmers will not be aware of a list of cities, 2 or 3 cities are missing; if in a list of temperatures, a value is missing … they will never realize)
With this we say that: “we are not going to worry about the objects in null that arrive”, because “null safety-?” It’s automatic.
A user could argue, we can control that null does not arrive … that is nonsense having the “null safety”, in other words having “null safety” and “controlling that it is not null”, it is too redundant, or you do one or you do the other, but both at the same time, it’s too annoying and it doesn’t make sense. Java looks better in this case.
Let’s imagine for a moment that we don’t care if they arrive in null:
var mySafeString2: String? = null val l = mySafeString2 !!. length // NULL POINTER (This reminds me of Java, friends)
I leave you another example that I have found more than a dozen.
val mySafeString2 : String? = null val aInt: Char = mySafeString2!!.get(1) // NULL POINTER (This reminds me of Java, friends)
The problem with this is that there are many ways to make it jump.
I don’t think it is necessary to put the dozens of code that make the nullpointer jump. (That is, we have a slightly improved Java? Are we talking about 70% improved?)
Sell me the bike saying it is new and new concepts. We all know what strongly typed means.
Can someone clarify for me why with “null safety-?” am i still getting null pointer errors?
The compiler “understands” what it wants to understand.
But the same in java can be done without problems.
There is always someone picky who will say:
“With ‘mySafetyString? .lenght’ we can control if null arrives or not and we don’t have to worry.”
The problem with this is that “we” need to know when nulls arrive and “have a checker”, to control them and if nulls arrive, do something else. As I said earlier if we have to do “null safety-?” + check that it is null, it is redundant. This is what this post is about.
Perdonar mi inglés como yo perdono a Kotlin
Updated 20:31h - 15/07/2021
I will continue to wait for the response of someone with experience.
Because those who responded to the post, did not respond to anything that I argued. They just looked at “!!” and the null. The problem goes beyond that. That’s not the point.
in other words having “null safety” and “controlling that it is not null”, it is too redundant, or you do one or you do the other, but both at the same time, it’s too annoying and it doesn’t make sense. Java looks better in this case.
it can give NullPointerException. So what’s the use of “null safety-?”
I do not think it is necessary to put more.