[ERROR NullPointerException] Null safety-? vs manually verify that the object is null (Redundant concept)

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)


ok…Say Bye to NullPointerException in Kotlin | Software Development

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 :slight_smile:

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. :slight_smile:

I’m not really sure what do you mean. When developing in Java, NPE is probably the most frequent exception I get. In Kotlin it almost never happens. I think I didn’t get it even once during 2 years of my full time development in Kotlin.

I think you misunderstand what null-safety means. It doesn’t mean you can’t anyhow make the code throw NPE. It means that the language is just more strongly-typed. For example, in weak-typed languages you need to remember which variable or property holds what object and if you make a mistake and access a property/method that doesn’t exist, compiler won’t tell you about that - you will get a runtime error. Java helps you with this by strongly-typing all objects.

But Java is weak-typed regarding nullability. You can’t say that a variable is nullable or not, so you need to remember that and if you make a mistake, compiler won’t detect this - you will get a runtime error. In Kotlin nulls are strongly typed, so once again, it is much harder to make such a mistake.


Because you’re explicitly ignoring null safety by using the !! operator, it’s literally described as such in the documentation:

The third option is for NPE-lovers: the not-null assertion operator (!!) converts any value to a non-null type and throws an exception if the value is null. You can write b!!, and this will return a non-null value of b (for example, a String in our example) or throw an NPE if b is null:

Thus, if you want an NPE, you can have it, but you have to ask for it explicitly and it won’t appear out of the blue.

There’s a multitude of ways to deal with nullable types described in the document that you have elected to ignore that don’t involve if(x != null) checks. Safe calls, elvis operator, safe casts, nullable extension functions.
Additionally, a type that is not nullable does not require a null check, ever, because it can’t be null.


As for your original question, the documentation linked by @chipays covers this. It is really clear, too. Maybe there is a language barrier?

But anyway, out of curiosity:

I wonder, what would you expect to happen here? If no exception should be thrown when you try to access null, what should be the value of l then after the allocation?


Yes, they can, but it’s really easy to write code where they can’t.

Any developers that have such a notion will have a terrible time in any language. No language can help developers who intentionally ignore errors and edge cases (language cannot make the problem space simpler) or who undermine or abuse the tools that the language provides (any language can be used incorrectly).

It’s more likely that they have a List<City> which will not contain nulls so nothing is missing. If they have a List<City?> then at least they know it can contain nulls which is an improvement over Java, IMO.

If you intentionally ignore a possible value, then that reflects badly on you, not the language you are using.

I’m not sure anyone has been able to understand what you are referring to here. You seem to be talking about two things related to Kotlin’s handling of null’s but I don’t know what they are.

Kotlin docs are accurate. This article … not quite.

Because you are trying to? :wink: You are not really using Kotlin’s null safety features at all. If you want to explore null safety try playing around with the String type instead of String?.

Kotlin’s philosophy is to be “practical”, not “pure”. It gives you the tools to side step its rules system but you have to do so explicitly (like with !!). You aren’t going to accidentally run into it in pure Kotlin (it’s still easy when dealing with Java APIs though :frowning: ).

Not the best error message but I wouldn’t say Java is better because you can write garbage code.

It’s complaining because it sees that mySafetyString must be null so mySafetyString!! will never return a value (thus it’s type is Nothing in Kotlin’s type system) and so it doesn’t know which overload to pass because Nothing can be passed into any of them because the code will never run. Nothing is a little weird at first, but it’s pretty cool once you get used to it.

It’s essentially detecting that you are trying to use an expression that will NPE.

mySafetyString? .lenght does not "control if null arrives. Giving mySafetyString a type of String or String? is you control whether null can arrive or not.

Kotlin doesn’t “fix” Java. Java can NPE so if you use Java APIs, they can NPE.


This is inappropriate towards those who did take the time to answer your post which frankly is pretty confusing. Please be respectful of the people here just trying to help each other out.


Because your post is quite chaotic and hard to understand. You seem to argument by providing examples of intentional misuse of null-safety feature. So you are correct - I really miss your point.

Null-safety is just a tool. It helps you better understand your own code and make it less error-prone. And it is very effective at doing this, it practically eliminates NPEs while keeping the resulting code clean.

Ok, if this is your main concern then I can explain.

Kotlin does not eliminate nulls or null checks, it does not make you not think about nulls. Null-safety feature is about being strict and explicit on where nulls are allowed and where not. It forces developers to properly handle nulls instead of trusting that they will do it properly by themselves (which they often don’t).

Let’s get some scenarios:

  1. You need to use some variable/field/return value of a method and to make your code null-safe, you add a null check. In fact, this value was never meant to hold nulls and it does not hold them, so you just added a dead code. In Kotlin, you would clearly see that it does not hold nulls cause of its type and even if you would try to add a null check, it would be a compiler warning.
  2. The opposite: you use some value and you think that it never contains nulls, but there is some rare case when it does. You don’t add a null check. In Java it results with rare NPE, in Kotlin this is a compiler error.
  3. You need to set some property or pass an argument to a method and you think it accepts nulls, but it doesn’t. In Java you get NPE, in Kotlin you get the compiler error.
  4. You designed your data model in the way that some data field can’t hold nulls. Now you see that you need to redesign it to allow nulls there. In Kotlin, after changing from not-null to nullable you immediately get a list of places that needs to be updated by properly supporting nulls (compile errors). In Java you need to search them manually and if you miss anything - NPE.

Of course, all examples could be replaced by scenarios with a team of people where two developers have contradicting assumptions about nullability of some data. Or by working with inexperienced developer who just doesn’t understand consequences of providing a null where it is disallowed.

So null-safety isn’t really about making your code shorter. If you need to make a null check in Java, you still need to do the same in Kotlin. But null-safety clearly tells you where you need to make a null check and where you don’t. It forces you to add these checks and warns you about redundant checks. It disallows to implement unsafe code (as long as you don’t intentionally “disable” the null-safety feature).

And yes, there are things like e.g. @Nullable. If you are an experienced Java developer, you document your code well, you rarely make mistakes and you work mostly with other experienced developers, so you practically never see NPEs then Kotlin’s null-safety won’t change too much to you. You will still have your null checks where they are right now. But in practice NPE is the most frequent exception type in Java and Kotlin practically eliminates this problem.


The fundamental questions of null safety design are all answered in this article: Null is your friend, not a mistake | by Roman Elizarov | Medium. I suggest everyone who have those type of questions to read it.


Nope. It’s not redundant. It’s actually the same thing. You get null safety by controlling what can or can not be null.

No, it doesn’t. In Java, there is no way to tell just by looking at a variable whether it can be null or not. In Java, you can just write mySafeString2.length, and the compiler will be happy about it. Then it suddenly throws. Or doesn’t. Or maybe sometimes throws.

In Kotlin, that just doesn’t compile. Of course, you can tell the compiler to shut up and just do what you want, by writing mySafeString2!!.length, but by doing it you’re asking for trouble, when in Java you get in trouble without asking for it. That’s exactly the reason why !! looks so ugly.

What is automatic? Your post is indeed very hard to follow. Null safety is not about not worrying about something. With null safety you either explicitly prohibit null values by using a non-nullable type, and then you don’t have to worry about nulls arriving, or you allow for nulls by using a nullable type, and then you have to worry about nulls arriving. In Java you don’t get to make that choice. You always have to worry about nulls.

If you mean the ? operator somehow allows you to ignore nulls and not worry about them, it’s wrong either. It’s about the situations when you do worry about nulls, but you don’t worry about what exactly is null. So when you write something like

if (order.customer?.address == null)
    // fail because the order must be assigned to a customer with a valid address

In this case you don’t really care whether it’s customer or address that is null, but you do worry whether they are both non-null or not. It’s nothing more than a syntactic sugar, and Java alternative would be

if (order.getCustomer() == null || order.getCustomer().getAddress() == null)
    // fail because the order must be assigned to a customer with a valid address

Except that Kotlin way is shorter, more efficient (as getCustomer() is only called once), and safer in case the first call to getCustomer() may return a non-null value, but a second one may return null.

But really, null safety is not about ? or !!. It’s about having nullable and non-nullable types to begin with.


This is not entirely correct. “I made him jump.” Coincidence ?, or did I just declare it null ?. I guess if I get the data from a DB call and there are null values ​​it will jump the same way in Kotlin if there is that statement. There is a mixed mess here. A very popular motto in Spain, “mixes merino with churros” - mezclas merinas con churros…

Now, you tell me that there is no redundancy of concepts. We go by point, slowly and with good handwriting.

Many values ​​can get null (did I say null? Yes, I said null, we confirm).

The way we’ve had as far as I can remember is that “any current existing language uses the logical call”! = Null ". Declaring in java it would be of the type: if (object! = Null) {…} else {… .}.

The problem is that Kotlin uses a concept called NS- ?.
With this we have the following problems.

    • How will we know the objects that did not arrive? (they have to have a way of knowing those who did not arrive)
    • Objects of type XML that we will have to control so that it does one thing or another. A basic example is jsonobject / jsonarray so that they work in a different way (An xml can reach objects or arrays)
    • External calls (SOAP, PLSQL, SQL … and an endless number of them to DB) (for generics / predicates) there are many times that you need to check the! = Null, due to if you have to make multiple casts of a type Pertinent object may come null
    • Connection to the DB
    • Check that an object has been released
    • Control stack overflow
    • Control a callback
    • Control a context
    • … It could happen to me all day, but, they would never understand that it is a duplicate concept.

All these problems are solved with:
if (object! = null) {…} else {…} for any language.

So why does Kotlin use a redundant concept if the if (object! = Null) {…} else {…} already exists?

Why does Kotlin use a system / concept (to skip the nules)?, as I said, (a good understanding, was the one who knew how to understand my arguments)
“Let’s imagine for a moment that we don’t care if they arrive in null:”
First, that it is omitting all the previous points and secondly, according to the “Kotliners” its code is more reduced. I see this the same but adding a “?” if (order.customer? .address == null).

In other words, you have a concept that you have to “study / learn / develop correctly” that is quite “annoying”. I don’t think I was born on Jupiter to see it. You don’t have to be very savvy to know that.

Kotlin NS-? it helps with some simple nules (obj.string), of course. But why instill another concept if obviously you are going to have to use the if (object! = Null) {…} else {…} in Kotlin?

Kotlin will use in many cases for all options I exposed the object! = Null, so why still have the NS- ?. Okay, I’m done with this, is it said like this in the US?

Another Spanish saying “A good understanding few words” - A buen entendedor pocas palabras.

I make a correction to you from Spain. (By the way, I can’t give you a very good grade). You see why it is important to study nulls.

// This can never go like this, this makes my eyes hurt when I see it.

Let’s first review the || operator. If the first condition is met, it will enter. In your case you put it right, but it is wrong. You are saved by being clever.

If you had an && operator, it would give an error in Java, or if the conditions were [if (order.getCustomer (). GetAddress () == null || order.getCustomer () == null)], you would get an error. You have been smart to put a ||. But it is bad practice and praxis.

Good practice is like a transaction. (may someone learn something today)

if (custom! = null) {

if (custom.getCustomer ()! = null) {



You can do if (obj! = Null || obj.getMethod ()) {} But it is bad practice if you use another type of operator or write them in a different position you will get a nullPointerException in case it is null…

No it doesn’t. You search the entire docs, you won’t find anything that’s named “NS-?” there. It’s a term that you invented for something that exists in Kotlin. Judging by the presence of the ? in this term, I am going to assume that you meant the ? operator, but it isn’t clear from what you write.

The “null safety” part of your term is still very confusing, though, because ? and “null safety” are two entirely different things. C#, for example, has ?, but doesn’t have null safety at all.

Null safety is just this:

  1. If a value (variable or return type) can be null, then you have to declare it nullable.
  2. If a value can’t be null, then you’re allowed to declare it non-nullable (and you better do!).
  3. If a value’s type is nullable, then you must check whether it’s null or not every time you access it.
  4. If a value’s type is non-nullable, then you don’t have to check whether it’s null or not (and you better don’t).

That’s it. Now back to the ? operator.

You call one of the most common idioms in most C-like languages a bad practice (using short-cutting && and ||)? You call. But what you just did, is named another reason why the Kotlin way of writing that is better. Since you seem to have completely ignored the other three I named, let me list again:

  1. The Kotlin way is shorter (this one’s obvious).
  2. The Kotlin way is more efficient due to less calls (the thing before ? is evaluated once, then saved into an invisible temporary variable).
  3. The Kotlin way is safer in case variables and properties can change at any moment (think of if ((request?.parameters?.size ?: 0) == 0) return with a request that’s declared volatile).
  4. The Kotlin way doesn’t force you to use a lot of statements and/or think of the correct order in || or && (that’s the one you inadvertently named).

Now if I had to write (request?.parameters?.size ?: 0) in Java with a volatile request, I’d need to go the way you call “a good practice,” but take a step further:

Request currentRequest = request; // need a copy in case it changes
if (currentRequest == null)
if (currentRequest.getParameters() == null)
if (currentRequest.getParameters().getSize() == 0)

Here, I’m assuming that Request is immutable, so once I take a copy, subsequent calls to getParameters() return one thing, and they are fast enough so I don’t care to optimize. If that’s not the case, then I’d have to write

Request currentRequest = request; // need a copy in case it changes
if (currentRequest == null)
RequestParameters parameters = currentRequest.getParameters();
if (parameters == null)
if (parameters.getSize() == 0)

This is just crazy. All I wanted to check is that I have a request with non-null and non-empty parameters before proceeding. In fact, if the subsequent code only used parameters and not the request itself, I’d take a step more and wrote this instead:

request?.parameters?.let { parameters ->
    if (parameters.size == 0)
    // now use parameters to do something useful

Now let’s assume that Kotlin doesn’t have ?, so I have to write it the Java way:

Request currentRequest = request; // need a copy in case it changes
if (currentRequest == null)
if (currentRequest.parameters == null)
if (currentRequest.parameters.size == 0)

Remember what I said about assuming immutability of Request. Well, it Kotlin, there’s another part of null safety that’s at play here. If parameters is a val initialized in constructor (that is, a final field), then the code above compiles (parameters is smart cast to non-nullable in the last if). If it is a non-final field or a getter, then it doesn’t compile because the compiler can no longer safely assume that this property can’t change! I’ll have to copy parameters to a local variable then. That’s called null safety because the compiler doesn’t allow me to accidentally write code that’s unsafe. If I really wanted to, I could force it by writing currentRequest.parameters!!.size, and then I’d probably put a comment explaining why it’s safe in this particular case.


As many people told you already multiple times, null safety feature isn’t really about removing != null checks or replacing them with something else, it isn’t about operators like ?. or ?:, etc. They are all just nice additions. But the main feature of null safety is a possibility to mark variables as nullable or not and force people to properly handle nullable ones. It is impossible to compare this with a Java equivalent, because… Java just doesn’t have it at all (edit: well, it could be compared to some lint checkers, but they aren’t part of the language).

But making things really simple here. Java always struggled with NPEs, there are tens of thousands of questions about NPE on stackoverflow. Kotlin’s null safety feature was designed specifically to solve this problem an it succeeded at doing this - there are almost no NPEs in Kotlin. Therefore, how can you say null safety feature is not needed or redundant if, as a fact, it solves a real and pretty big problem? This is not hypothetical - null safety already proofed that it woks. So what is the point of this discussion?

You need to also understand that there is a language barrier here. I’m not sure what do you mean by saying things like: “arrive”, “jump”, “NS-?”. Some of these phrases seem like a bad translation to English and some are just your terms that you use, but you didn’t explain them to others. It is hard to get your point if half of your sentences are at least enigmatic.


I think it is convenient to stop arguing with you :).

If I can’t abbreviate null safety to “NS” and “remembering to put a”? “In null safety and abbreviate everything to” null-safety-? “Or” NS-? ", We’re on the wrong track.

In case you say it was not clear. (I comment on points).
N = Null
S = Safety
(remembering to use the printable ACSII “?” character)
But you tell me I can’t abbreviate it as NS -? … please

Please don’t anyone call you “NS”. We will call it Null Safety from now on. (If not someone could understand No Scope …).

What a pitiful talk. I thought this talk would be fruitful, but no.
Now, if your argument is to try to discredit by saying “this”, I think I have nothing more to say. Feel free.

Then you have a concept that is of no use. That is, you have the “NULL SAFETY” and then the manual null check (the usual).

There are no short cuts in life. The fast path is not always the best … “Excuse me, it seems that yes for many people it is better to go fast than to understand concepts”, I understand.

If it is simply used to not give you some simple access or variable nulls, I repeat it is a redundant concept. Every programmer should understand any code and understand where the nulls would occur. If not, we will always have null safety

Putting it in the form of a transaction or in this way are valid depending on the purpose.


There are simply many ways to do it. Normally Java APIs use the ternary operator a lot.

Returning to Null Safety

It is simply knowing the structure well. In java you have the ternary operator.
But imagine that you don’t have enough with what I tell you. Java +8 largely solves this.
For example:

Stream collectionAsStream (Collection collection) {
return collection == null
? Stream.empty ()
: collection.stream ();
Here are good practices: https://www.baeldung.com/java-null-safe-streams-from-collections

Kotlin is shorter than Java with a redundant concept, yes.
Now if your prism for thinking that Kotlin is better and you want to see it as non-redundant, it seems legit to me.

Sometimes learning that a language that is updated is more expensive, on the contrary, it is easier to make excuses than to learn it again. it seems legit to me.

The problem is that we already have the usual “! = Null”. If you get used to null safety, there will come a point where you don’t know where the nulls are going to come from and finally you will end up putting “! = Null”. Tell me you don’t have any “! = Null” in your code. If so, I think I will become a Kotliner, meanwhile, I am watching the market evolve.
Vices are bad. (Waiter another drink!)

To sum up…
You “Kotliners” have an affinity with Null Safety. I think it’s great.
I will continue to use the! = Null. You may think, there is going to be a lot of lines of code, a lot of confusion … “blah blah”. I just have a Generic function with predicates that allows me to check everything I want.

Each one with its booklet.

“Now I understand better why there are so many political parties in each country and especially why they need leaders”

Este argumento me permitiréis ponerlo en español.
Discutir en un foro donde todos son del equipo contrario, es bastante complicado. No me imagino entrando en un foro del equipo contrario y que ellos se hagan una autocrítica.
Fan: “Mesi hoy no ha marcado porqué no le han pasado el balón”
Persona normal: “Mesi no ha jugado bien”
Fan 1: “argumentando…”
Fan 2: “argumentando…”
Fan n+1: “argumentando…”

Maybe different vocabulary will help?

Do you understand the difference between an object that’s a reference and an object that’s not a reference?

It’s not clear to me that you do, so forgive me if I come across as condescending; I don’t mean to. But in Java, all objects are references. Hence, they can be null. Hence, you must always, always check if they are null.

In Kotlin, you can create objects that are not references. They are never null. Hence, you don’t have to check if they are null.

Surely you understand this basic difference?

Don’t take my word that it is incredibly useful, and leads to cleaner and clearer code. Spend some time studying other people’s code. Read up on why the Eiffel language implemented null safety. Read why Google promotes Kotlin as the standard language for programming on Android – over languages Google itself has developed!

If you want to say that five hours of Kotlin hasn’t convinced you that null pointer safety is useful, or that JetBrains’ implementation of the concept doesn’t work, then pretty much everyone who’s spent a lot more than 5 hours with it will understand where the problem lies: you need more experience – and not just with Kotlin, but with Java, with C, and with pretty much any other language where null causes routine issues.

If you understand the basic difference, and you understand that it’s important, but you don’t how Kotlin makes code cleaner and clearer on average (as opposed to particular use cases that may be common to you but not the average programmer), then you could ask specifically about that.

But it’s not clear to me where your confusion lies.

The topic of the conversation is moving away from what we really want.

The explanation of why null safety is or is not redundant having other arguments.

Now, if your egos problem prevents you from seeing this, and you start to blacken the post, unfortunately it will not help future users.

Hi. I still think you and everyone who is trying to help here mean different things by the term “null safety”. As others have pointed out, “null safety” has nothing to do with how we check for null values. The term “null safety-?”, i.e. with the question mark, is unclear because we don’t know if the ? refers to the ? used when specifying a nullable type, e.g. String? or if it refers to the ? in the ?. and ?: operators.

“Null safety” in Kotlin is the fact that you as a programmer specify whether a variable is nullable or not. Example:

var nullableString: String? = null // the ? makes this variable nullable
var nonNullableString: String = "hello"

If you write var nonNullableString: String = null you will get a compiler error stating that “Null can not be a value of a non-null type String”.

Sometimes you do want to use a nullable variable because null has a meaning in your data model. In those cases you have to check for null before referencing the variable and you are free to use any available syntax for that, e.g. != null, ?. or ?: depending on the situation.

You also point out that sometimes nulls might arrive from external sources, e.g. JSON, XML, an SQL database or a Java API, even if null is not considered a valid value for your variable. That is of course correct and in that case you might need a temporary nullable variable, e.g. String? which receives the value. The nice thing about Kotlin null safety is that once you have validated the data you can pass it on to other parts of your application using non-nullable types, e.g. String and those parts don’t have to do any null checks. In fact, if you do a null check anyway, e.g. if (nonNullableString != null) you will get a compiler warning stating that. “Condition ‘nonNullableString != null’ is always ‘true’”. Example:

fun functionAtApplicationBoundary() {
    val nullableString: String? = getStringFromAJavaApi()
    if (nullableString != null) {
        val nonNullableString: String = nullableString

fun coreApplicationFunction(nonNullableString: String) {
    val length = nonNullableString.length // no need for null check

Nothing of it is anywhere clear. You keep on mixing up the ? with null safety despite multiple people telling you that one has nothing to do with the other, as these are completely orthogonal things. In fact, your posts are so unclear, that I’m like only 90% sure that you’re talking about the ? operator, and therefore not talking about null safety at all. Therefore I think it makes best sense to just stop this pointless discussion here. If you’d rather like to continue this discussion, please figure out what exactly you’d like to talk about. As you’re currently like “I’d like to talk about politics, so please explain how come Venus spins in the wrong direction, but try not to derail off topic (it’s politics, remember?).”.


I like your point.

The term how we check for nulls and null safety are two different things, that is clear, but why modify an already effective concept like “! = Null” (which works for everything) for the Null Safety concept?
I think the confusion comes from here
(! = null) => It is used to check anything / reference / not memory allocation … it is not null
(Null Safety) => you manually say that that object is not null, but there are exceptional cases as I showed that it can give a NullPointerException error (here we use the jargon, the error can JUMP)

Now, if having the concept (! = Null) “FOR ALL KINDS OF INSTRUCTIONS” why add a different concept?

you tell me:

In this statement it looks very simple. But let’s imagine that we have a large project with many files and by some chance we have an error of the NullPointerException type like the ones I mentioned in the first post, because supposedly the data arrived null or did not arrive using Null Safety. Then we would have to resort to the basic concept that is “! = Null”.

In addition, we always keep in mind to use the concept “! = Null” for everything, as I mentioned in my points. But it seems that Kotlin implements his own style.

Simply if the question is for not writing a condition or code reduction … If it is because of this, I would not know what to say.

However I respect your argument.

Just for technical correctness, this is not true at all. Both String and String? are internally represented exactly the same - as Java String. And they are references.