Home > database >  Can someone explain me what null is for?
Can someone explain me what null is for?

Time:08-20

I looked many videos but I didn't understand anything about null. Is it important? What is null? What is used for? Is there any difference between kotlin and other languages? Please explain it simple as you can.

CodePudding user response:

Nullability does not have an inherent purpose; a for. Otherwise, null is something that happens.

Something is null when it is no longer allocated to a memory reference. This means the instance no longer exists, or it never exists.

You can have null variables because something didn't happen, or because you can support null. For example:

suspend fun getServerResult(id: String) : Result? {
    val localModel = source.findInDb(id) ?: return null
    //...
}

In the above case we can't proceed with the server operation because we don't have the local model that we need, so we can return null.

data class SomeScreen(val screenText: String?)

someTextView.text = someScree.screenText

In Android TextView supports setting null text, it clears the text.

However, there are better patterns for everything, always. So in the first example, you could return Error and never return null. In the second example, you could have "" empty text instead.

In Kotlin, nullability sprout from the root inheritance. Everything always inherits from Any or Any?. In comparison with Java where everything stem from Object, which was nullable by default.

CodePudding user response:

The simple answer is that null is what a reference points to when you don't have an object of the correct type for it to point to.

There's no single reason why you might not have such an object, and so there's no single meaning for null; it will depend on the context. But most of the common meanings are fairly similar (and not specific to Kotlin); there's a lot of overlap but also subtle differences:

  • An empty value. For example, if you have an object representing an address, its house-number field might be null for addresses that don't have a house number. Or a leaf node of a binary tree might have its ‘left’ and ‘right’ pointers set to null to indicate that it has no child nodes.
  • An unavailable/missing value. For example, you may not be authorised to access certain data fields within some object; in that case, they may be returned as null. Or if there's a database error, you may choose to return null for non-critical fields instead of throwing an exception.
  • An unknown value. For example, a genealogical database may store null for birth dates which are uncertain.
  • An unspecified value. For example, when creating a TreeSet, you can specify a Comparator for it to use when comparing two elements. But you can pass null, to get the elements' natural ordering instead.
  • An uninitialised value. Sometimes you don't have all the relevant data until after an object has been initialised; so what should its properties hold before that? You could specify values such as empty string, but it's neater and safer to use a special value such as null.
  • An invalid value. For example, if an input string isn't a valid date, then you might store null in the corresponding date property to indicate this.
  • An inapplicable value. For example, the maxByOrNull() function gives the largest value in a collection. As long as the collection has at least one element, then it can find a largest (though it may not be unique); however, it can't do so if the collection is empty, so it returns null in that case.
  • A default value. For example, when creating a connection to a remote system, it might allow you to pass null for parameters such as time-out durations that you don't care about, so it can pick the most suitable defaults.
  • An unchanged value. For example, if you pass an object used to update a database record, you might make all its fields nullable, and use null to indicate that the record should keep its existing value for that field.

The common threads are:

  • They all represent a value which is absent for some reason.
  • And there will usually be some context (often spelled out or at least implied in the documentation) providing the exact meaning.
  • Related