How to check if it's null from static variable of other class

Hi guys I want to check if the value of the variable from other class is null. So I make the static variable to get the value, but unfortunately static variable cannot be null. Any solution how to solve this problem ? I want to check the static variable from Sensor class to be checked in TriggerShoot class. Thank you..

 

What about letting it false? Tell the idea to do with that var.

 

Ok I want to make it more understandable. So I want to check the toDestroy variable inside method DestroyThis. The problem is anytime you want to check that it never be null because toDestroy = Sensor.containTarget which is the Sensor.containTarget is a static variable.

 

ANd if you set it to private and create a getter for it?

 

Doesn't work I already tried it. Static variable can only be null if it's on it's class. If you call the static variable from different class the result is NOT null.

 

No, I mean, don't use static, but private <T> containTarget, whose value will be internally setted by a class method. Later, you create the getter and just do:

Code (CSharp):

1. toDestroy = Sensor.GetContainTarget();

I don't know if it has to be forced to be static, but if not, maybe you should rebuild the logic proccess for it.

 

Oh wow, I never use something like private <T> before. How do I use it ? And how does it work ?

 

<T> is just a way I had to tell you to use something like string, int, etc.

 

Static variables can also be null when the type itself is nullable.

You never call DestroyThis() in any of both scripts, so it won't check if it's null and it won't destroy anything.
If you call it somewhere, please add the code.
You can paste code snippets directly using code tags.

A few other things to mention:
- You allow to bypass the encapsulation of captureTarget.
- anything that interacts with the trigger can set and reset the variable, but maybe you've shortened the code in order to demonstrate the problem here.
- isMissed would always be set back to "false" immediately because the code continues to run, the destruction of a gameobject does not happen immediately

 

Can you give me the sample code ? I don't really get what you mean sir..

Actually I call it on Button Event in Canvas. So the scenario is when I press the button, it will call the DestroyThis method. Then inside the DestroyThis method, it checks does variable toDestroy equals null ? And the problem is toDestroy is empty (not null) so it will always return false.

 

What do you mean by 'it's empty' ?
I tested your code (with the button event and all that stuff) and it works just like I expect it to work.

Once I destroyed the object, the script no longer runs into the if statement because the comparison to null is true, in other words toDestroy != null is false.

Anyway, if you refer to the boolean "isMissed" => that will always be false not matter what happens in the method.

 

I mean it's really are empty whenever I clicked the button

For now let's just ignore that variable. I'm gonna change that later.

 

Ah, that's what you mean. Well, this just indicates that it is 'really' null, the 'null' which you may know from usual C#.
In Unity, there is also a fake-null object.

You may get the following output:
1) ToDestroy : (nothing here just like the output in your picture)
2) ToDestroy : SomeGameObjectsNameHere
3) ToDestroy : Null

1) This means the variable is really null (the null that you may know from usual C#). Nothing has been assigned or it was explicitly set to null. You can test that, just insert a cast to System.Object and it will be equal to null.

2) Nothing to explain here, some object is being referenced.

3) This happens when Unity's fake-null object is assigned to the variable. They've overriden the == operator to act accordingly and gather useful information. This happens if, for instance, an object has been destroyed.
In contrast to 1), a cast to System.Object and a subsequent comparison to 'null' would evaluate to 'false'.

One more way to demonstrate the difference is the access to a member of the object.
1) would throw a NullReferenceException, whereas 3) throws a MissingReferenceException


For further information about that, take a look at this.

 

So based on your reference, I cannot use custom == operator instead I have to check it by destroying my object is it right ? (I'm not really good at english so correct me if I missed something important).
My game is like Deer Hunter. In my game there is a crosshair that checks if there's an enemy passing on it (It's 2D game). So when the game has been started, the crosshair should be null. This condition is used to make the enemy near the crosshair scattered, but if I successfully shoot the target while they are near from crosshair they won't scattered. Thus I don't want to destroy the enemy object when the game has been started.

 

That's not what it says. You can use it, it's even supposed to be used.
As mentioned in the blogpost, it's an editor feature to help game developers to track nasty bugs more easily.

If the null check evaluates to false, it just means that the variable does not store a valid reference to an instance of the variable's type, no matter whether it's actually null or fake null. In your case it wouldn't matter either whether it is null or fake null. Real null for the static member just means the variable hasn't been assigned at all or has been set to null explicitly, fake null means the object has been destroyed at some point.

In both cases you want to avoid the attempt to access any members, therefore you insert the null check. Otherwise exceptions will be thrown.

Btw, there's also another alternative which checks Unity API types (or derived types like your custom MonoBehaviours) for null/fake null.
You can simply use the variable as if it was a boolean, like

Code (CSharp):

1. if(myGo)
2. {
3.     //...
4. }

 

So how to do the null check in my case ? Seriously I'm getting confused with this null problem after I read your reference and another thread that discussed about the null in Unity.

 

You can keep it the way you've done it, unless I totally misunderstood your concerns.