CODEWITHSUNDEEP
javakotlintypesnullability
Сергей Андриенко
Сергей Андриенко

Reputation: 11

How to get unknown nullability function return type in Kotlin?

What I want to achieve is to get Any! return type from function, so I can determine myself whether to handle nullability or not. The only way to get this type I found is to call a Java function. For example:

public static Integer getInt(JsonObject json, String key) {
    return json.get(key).getAsInt();
}

This way I can use it in Kotlin as either Nullable or Non-nullable type. getInt(json, "id") ?: 0 or getInt(json, "id"). Kotlin compiler won't complain about nullability, because the return type is Int!.

Is there any approach to create return type like this in Kotlin without using Java?

P.S. I don't really want to put !! in each function call or create two functions in Kotlin like getInt(...) and getIntOrNull(...).

Upvotes: 0

Views: 100

Answers (1)

tyg
tyg

Reputation: 14790

Just declare it as Any?. The compiler will enforce by default that you handle the nullability afterwards. when you decide to ignore the nullability later on, just apply the !! operator.

To address your reluctance to go this way: The null-safety in Kotlin is one of the major advantages over Java. Having a reference that can be invalid at runtime because it unexpectedly doesn't point to anything is a huge source for bugs. Tony Hoare even calls it his billion-dollar mistake that he popularized the null reference in the computing world: A lot of even statically typed programming languages adopted the use of such null references which was - and still is - a major cause for system failures that I am willing to bet did cost the global economy a lot more than just one bilion dollars in erroneous results, disrupted service availability and maintainance.

Now we have Kotlin as a modern main-stream programming language that incorporates nullability into its type system so you already see at compile time where you try to access a reference that might be non-existing at runtime. It even allows you an elegant way with the fallback operators ?. and ?: to handle these cases and once checked the type inference system automatically applies smart-casts so you do not have to repeat these null-checks. It even allows you to ignore all warnings and access the reference nonetheless with the !! operator (which you shouldn't by the way, which my original answer probably wasn't that clear about). It effectively eliminates an entire class of errors.

This is like a dream come true. I've seen a lot of programming languages over the last thirty years that loaded the responsibility for keeping track of the type and the nullability of a type off to the developer. Yes, a capable developer can handle that to a certain degree that may appear acceptable, but that doesn't scale well when the code base grows and since we are talking about humans, there will always be a remainder of undetected bugs. Unless you are Donald Knuth, of course. But even an extraordinarily capable developer will find that letting the compiler handle null-safety will take a lot of mental load off of them, freeing capacities that can be used elsewhere.

The evolution of programming languages is a long history of insufficiencies that were overcome bit by bit. You can see null-safety in Kotlin as a gift given to you by generations of programmers that had to endure all the problems that are associated with unchecked nullabilities.

Don't throw this gift away so carelessly. There are very good reasons why null-safety is implemented in Kotlin as it is, even when you cannot see the benefits at first glance and feel hindered by the compiler constantly nagging you. I promise you that your use case of retrieving map values or deserializing JSON can be elegantly implemented with Kotlin's null-safety as it is intended to be used. Try to embrace this.

Upvotes: 2

Related Questions