i would expect an Exception.

# announcements

[0rph3u]

i would expect an Exception.

[Shawn]

I’ve never used Room, so I’m not sure how it builds DAO instances

[Shawn]

also I feel like an option type would be much more idomatic

[Shawn]

but this is perhaps not exactly a Kotlin-specific issue

[karelpeeters]

Can you show us the signature of findById? Are you sure it has return type User ans not something like User!?

[0rph3u]

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.

[karelpeeters]

Is findById your code? Is it Kotlin code? Is it written in Java?

[karelpeeters]

I think you need to read this: https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types

[0rph3u]

https://imgur.com/aIdGe3X

[0rph3u]

https://imgur.com/Cl4Tu6Q

[karelpeeters]

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.

[karelpeeters]

So it happily returns null

[karelpeeters]

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.

[karelpeeters]

I'd say the solution is to only use nullable types for functions like this.

[0rph3u]

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 🙄

[Shawn]

it’s a hairy situation since not even platform types really covers this specific use case

[karelpeeters]

Right, no one can check this since it's the interface implementation not respecting the contract.

[karelpeeters]

It's actually the Dao codegen that should see the @NotNull annotation on the interface function and refuse to compile.

[Shawn]

ah that’s a good point, I was thinking just from the compiler/IDE pov