https://kotlinlang.org logo
Title
u

0rph3u

06/11/2018, 11:37 PM
i would expect an Exception.
s

Shawn

06/11/2018, 11:38 PM
I’ve never used Room, so I’m not sure how it builds DAO instances
also I feel like an option type would be much more idomatic
but this is perhaps not exactly a Kotlin-specific issue
k

karelpeeters

06/11/2018, 11:39 PM
Can you show us the signature of
findById
? Are you sure it has return type
User
ans not something like
User!
?
👆 1
u

0rph3u

06/11/2018, 11:41 PM
yes option would be the right way, this is a temporary version the thing is i forgot the ? on the return type and the test still passed.
k

karelpeeters

06/11/2018, 11:42 PM
Is
findById
your code? Is it Kotlin code? Is it written in Java?
u

0rph3u

06/11/2018, 11:44 PM
k

karelpeeters

06/11/2018, 11:45 PM
Ah I see, the Dao framework is implementing that interface (from a java point of view), and it doesn't know about kotlin's null safety.
So it happily returns
null
And the interface can't check whether the non-nullability is enforced because it's an interface, and the calling code trusts the interface, checking for
null
on every single call would be infeasible.
I'd say the solution is to only use nullable types for functions like this.
u

0rph3u

06/11/2018, 11:51 PM
yeah, you are right, room's UserDao_impl is in java and returns null, but i believe there should be something in place to prevent this, the IDE even tells me that it will never be null 🙄
s

Shawn

06/11/2018, 11:52 PM
it’s a hairy situation since not even platform types really covers this specific use case
k

karelpeeters

06/11/2018, 11:53 PM
Right, no one can check this since it's the interface implementation not respecting the contract.
It's actually the Dao codegen that should see the
@NotNull
annotation on the interface function and refuse to compile.
👆 2
s

Shawn

06/11/2018, 11:55 PM
ah that’s a good point, I was thinking just from the compiler/IDE pov