Interface belonging to expired Monobehaviour is "null" not null; sneaking past null check

Unity Engine
,
1

EDIT: The solution is to perform the following additional check:
csharp** ** if (kvp.Value.unboxed is UnityEngine.Object o) { if (o == null) continue; }** **

The following code is crashing with a null reference exception:

        foreach (KeyValuePair<string, ContextBox> kvp in all)
        {
            if (kvp.Value.unboxed == null) continue;
            CareerData.SaveString("CTX_" + kvp.Key, kvp.Value.unboxed.UID());
        }

Single-stepping through, the exception arises inside UID() because the monobehaviour whose interface I am holding in the ‘unboxed’ variable has been destroyed.

VisualStudio displays the value of unboxed as “null”, not null. Presumably, the fact I’m holding an interface reference rather than a monobehaviour reference is bypassing the usual safeguards and sneaking past my null check.

Not all IContext interfaces belong to monobehaviours. Is there a safe test I can make to fix this, before I throw my hands up and wrap the whole thing in try/catch?

1 Like
2

Is it simply because you’re iterating KVP<string,ContextBox> when you should be iterating KVP<string,IContext> ?

Either way, not sure what your .unboxed property does… is that what returns it as an IContext?

In other news, boxing / unboxing is often a sign that you need to reconsider your data design to avoid it.

3

It’s not that kind of boxing :slight_smile:

IContext in our game is a performant interface for accessing properties by string name (and more than that; parameters can be passed in the string too to influence the result). A ContextBox is a persistent named slot for an IContext. The upshot is that designers can do things such as reference “{PhoneCaller.FullName}” in our localisation text file and the Context system will toddle off and ask whatever’s slotted as “PhoneCaller” for its “FullName”. Or visual appearance. Or gender. Or whatever.

The gotcha here is that if you retain a reference to an expired UnityEngine.Object as an interface, the interface will pass a null test even though a direct reference to the object would fail it.

I’ve found a workaround and will add it to the OP.