If doc says that something can't be null e.g.Toybox.ActivityMonitorg.getInfo() and I feel it shouldn't be null because it's a core of system I don't waste code and don't check null especially in  frequently calling places like onUpdate.

But yesterday in midnight I've noticed that BodyBatteryIterator returns null for some time (any reset?) but because it's still problem with SpO2 history and I have one function reading data from all history I check null and it has saved me !

That's a good question. And I don't have a good answer to it because even my behavior regarding how much I can believe the documentation is not 100% consistent. However let's assume someone didn't add null check, and released the app, and got some null pointer exceptions from ERA and then added a null check. Worst thing that could happen is that the optimizer removes it. So maybe it would be safer (I'm not saying better) to instead of removing the null check display a warning (possibly one that could be suppressed somehow either with some kind of annotation or setting)

flocsy🤠 said:

instead of removing the null check display a warning

That does sound like the best option - if I can do it reliably.

1. You add a lot of code to check all nulls so your optimisation is worse.

2. Optimize means optimise so you should optimise developer code not add additional.

3. And if you check that something is null what dom you want to do? The only thing you can do is assign default value from developer. so it's easy to do writing additional function

 ifNull(value, default) {return value == null ? default : value;}

and eventually inline it in a place where is used.

_psx_ said:

You add a lot of code to check all nulls so your optimisation is worse.

2. Optimize means optimise so you should optimise developer code not add additional

I'm not really sure what you're trying to say...

Currently, if my optimizer detects a comparison, and it can statically determine the result of the comparison, it removes it.

I've been adding some type awareness, and as a result, the optimizer started removing some null checks, where api.mir asserts that a function can't return null. If the documentation/specification is correct, then thats a good thing to do. I know that *I* sometimes add null checks just in case, without checking the documentation. So it would be nice if the optimizer could get rid of them. But it looks like the documentation is incorrect - so doing that optimization is going to cause more harm than good.

I've never even considered *adding* null checks that the developer didn't add; just removing ones that shouldn't be needed (but now Ive decided there's no way to do so safely).

My plan for now is to do what flocsy🤠suggested, and just issue a warning. Then the developer can decide whether or not to remove the null check.