Colton Idle

12/30/2021, 4:11 PM
I've got a requirement to make my deserialization crash during runtime on "internal" builds, but not crash on external builds when I get data over the wire that is null when it's not supposed to be null. So with moshi, unless I declare something as explicitly null, I will not be made to handle nullability in that type in my code (makes sense) but "moshi" will still give me a null value if it's sent explicitly over the wire. So now I basically have a fork in the road in deciding on how to move forward. 2 options from what I see: 1. For every model... create two models, put one in /external and one in /internal. The ones in /internal would not be nullable, while the ones in /internal would be nullable which would make me handle nullability, but I would crash on deserialization in internal builds. 2. I can do a "check" on my data when it comes down and just make everything nullable, but in my checking layer I would just verify that my data is in a good state. I could have sworn I read a stackoverflow answer from Jesse Wilson on this topic a while back and he basically said something along the lines of "instead of depending on your deserializer to do this sort of checking for you, you can just do it yourself and the checking would then not be "hidden" in your deserializer." Anyone got any opinions on how to move forward with this? I think I'm leaning on option 2. Make everything nullable (because even though my backend says "hey we won't send you null" sometimes it does get through. And then there are some other invariants I could assert. i.e. Hypothetical, but person age will never be 0. If you get zero something is terribly wrong. In that case, I could crash in internal builds, but I could set some kind of default (or remove the feature from the UI) in external builds. I would love to just always crash in both internal/external, but I was overruled on that. 😢