Hi guys, I got a question in relation to a recent ...

# announcements

[Daniel]

Hi guys, I got a question in relation to a recent work problem:

What might be the reason for not checking if the returned value of a function is not null when its defined as not null?

To explain a bit: We have the input parameters checked with Intrinsics.checkParameterIsNotNull(..., "...."); but not the returned value.

The first question would be, how can this happen that a returned value is null even when its defined as not null? Unfortunately we got a data class for a backend response wrong: We set a property of the data class as non null, but it was nullable in the backend. So Gson was putting null in it.

The said property was then propagated through different methods via return and way higher up something crashed. If there were a Intrinsic check in place in every method we would have had an easier time debugging the issue.

There is most definitely a reason for why the kotlin team decided against it and I am curious for it! 🙂

[groostav]

was this pure kotlin aside from gson? could a platform type sneaking around be to blame?

[Adam Powell]

gson breaks rules since it'll instantiate objects without calling constructors. You might also consider moshi with its kotlin codegen processor

[groostav]

So, to the spirit of the question, kotlin was already pretty concerned about the performance of their null checks in methods as preconditions, putting it as a post-condition would kind've double the problem for arguably redundant coverage. I dont know if thats the reason, but the kotlin team are a pretty performance oriented bunch.

[groostav]

to the specifics of the question, when mapping from java libraries to kotlin I generally find you have to do explicit null checking, because most of the kotlin null-safety is done statically. The runtime parameter check is nice, but not reliable, so if you're calling into a java component with a java-platform signature, you should do an explicit null-check.

[Paul Woitaschek]

Its just reflection. You can also take an data class with non nullable properties, instantiate it and then null the underlying references through reflection

[Daniel]

It really was pure kotlin in our case, but as you said: Gson doesn't care if a variable is non null. Funny thing is that the crash was detected in a setter of all the things. So in an assignment basicly xyz = null in disguise. Funny things you encounter 😉